Copr package build fails on python-nocaselist package

[Andreas R Maier]

Hi,
I requested review of the proposed package in 
https://bugzilla.redhat.com/show_bug.cgi?id=1880953 


Andy

> Begin forwarded message:
> 
> From: Andreas R Maier 
> Subject: Fwd: Copr package build fails on python-nocaselist package
> Date: 21. September 2020 at 09:07:32 CEST
> To: devel@lists.fedoraproject.org
> Cc: Robert-André Mauchin 
> 
> Hello Robert,
> I suspect the reason I get the python-%{srcname}-%{version} in the .tar.gz 
> file is that I was setting up COPR to use "rpkg". When using "copr-cli build" 
> as shown in your mail, it works on COPR. So I think we can ignore that issue.
> 
> At this point, I can successfully build locally (with "rpmbuild -bb"), on 
> Koji (with "koji build"), and on COPR (with "copr-cli build").
> 
> I cannot yet build locally with "fedpkg mockbuild" or on Koji with "fedpkg 
> scratch-build", and I suspect this is because there is no repo for the 
> package yet and/or because I have not set up the mock environment on my local 
> Fedora.
> 
> What I still don't understand is the package name: "rpmbuild -bs" creates an 
> SRPM with package name "python3-nocaselist" while "fedpkg srpm" creates an 
> SRPM with package name "python-nocaselist". What will be the package name in 
> Fedora at the end of the day?
> 
> Andy
> 
>> Begin forwarded message:
>> 
>> From: Robert-André Mauchin mailto:zebo...@gmail.com>>
>> Subject: Re: Copr package build fails on python-nocaselist package
>> Date: 18. September 2020 at 13:46:53 CEST
>> To: Development discussions related to Fedora > >
>> Reply-To: Development discussions related to Fedora 
>> mailto:devel@lists.fedoraproject.org>>
>> 
>> The archives in your SRPM are different:
>> - on COPR the root directory of your archive is python-%{srcname}-%{version} 
>> - on Koji the root directory of your archive is %{srcname}-%{version}
>> 
>> Check that you have deleted python-%{srcname}-%{version}.tar.gz before 
>> regenerating the SRPM.
>> 
>> Also I never use rpmbuild anymore, I do everything in the same directory 
>> with 
>> fedpkg:
>> 
>> ## Building the Fedora package
>> 
>> ### Build the source RPM locally:
>> 
>>rm *.tar.gz *src.rpm
>>spectool -g *.spec && fedpkg --release f34 srpm
>> 
>> ### Build the binary RPM locally in a mock chroot:
>> 
>>fedpkg --release f34  mockbuild --mock-config fedora-rawhide-x86_64 -N
>> 
>> Build logs and RPMs (if any) are in the results subdirectory
>> 
>> ### Build the binary RPM with the Koji build system:
>> 
>>fedpkg  --release f34 scratch-build --srpm --fail-fast
>> 
>> ### COPR:
>> 
>>copr-cli build python-nocaselist *.src.rpm
>> 
>> 
>> 
>> No idea where python-%{srcname}-%{version} in the .tar.gz is coming from, 
>> neither pypi or github have that archive. Maybe it's an artifact of building 
>> the SRPM with rpkg?
>> 
>> ___
>> devel mailing list -- devel@lists.fedoraproject.org 
>> 
>> To unsubscribe send an email to devel-le...@lists.fedoraproject.org 
>> 
>> Fedora Code of Conduct: 
>> https://docs.fedoraproject.org/en-US/project/code-of-conduct/ 
>> 
>> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines 
>> 
>> List Archives: 
>> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org 
>> 

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

[EPEL-devel] EPEL Playground - Policy and Plans

[Troy Dawson]

EPEL playground (currently only for epel8) has recently changed it's
overall policy.  That new policy can be found here.
https://fedoraproject.org/wiki/EPEL/Playground

The biggest policy change is that epel-playground is not meant to be a
stand-alone repository.  If you use epel-playground, you are expected to
have the regular epel repository enabled.

Going along with that stand-alone change is the change that we will no
longer be auto-building all epel builds in playground.  This means that all
instances of package.cfg will be removed, new epel branches will not have
package.cfg in them, and requesting an epel branch will not automatically
request a epel-playground branch.

We will also be cleaning up (untagging) all automatically built, or old,
playground packages.

Not everything is happening at once.

SCHEDULE:
* Thursday September 24 - All package.cfg files will be removed from all
epel8 dist-git branches.  If you want to remove yours before then, that is
fine.
* Thursday October 1 - All automatically built, or old playground packages
will be untagged from epel-playground.
* Done (but not verified) - New epel8 branches should not have package.cfg
in them.
* Sometime Soon - fedpkg will be updated to not automatically request a
epel-playground branch each time an epel branch is requested.
https://pagure.io/fedpkg/issue/414

We appreciate all the input we've gotten from everyone.
Please pass this information on wherever you feel it is needed.

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

Fedora-33-20200921.n.0 compose check report

[Fedora compose checker]

No missing expected images.

Failed openQA tests: 2/181 (x86_64)

New failures (same test not failed in Fedora-33-20200920.n.0):

ID: 673583  Test: x86_64 universal upgrade_minimal_uefi@uefi
URL: https://openqa.fedoraproject.org/tests/673583

Old failures (same test failed in Fedora-33-20200920.n.0):

ID: 673532  Test: x86_64 KDE-live-iso desktop_notifications_postinstall
URL: https://openqa.fedoraproject.org/tests/673532

Soft failed openQA tests: 9/181 (x86_64)
(Tests completed, but using a workaround for a known bug)

Old soft failures (same test soft failed in Fedora-33-20200920.n.0):

ID: 673457  Test: x86_64 Server-dvd-iso install_vncconnect_client
URL: https://openqa.fedoraproject.org/tests/673457
ID: 673476  Test: x86_64 Server-dvd-iso install_vnc_client
URL: https://openqa.fedoraproject.org/tests/673476
ID: 673503  Test: x86_64 Workstation-live-iso desktop_update_graphical
URL: https://openqa.fedoraproject.org/tests/673503
ID: 673516  Test: x86_64 Workstation-live-iso desktop_printing
URL: https://openqa.fedoraproject.org/tests/673516
ID: 673536  Test: x86_64 Silverblue-dvd_ostree-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/673536
ID: 673539  Test: x86_64 Silverblue-dvd_ostree-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/673539
ID: 673553  Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud
URL: https://openqa.fedoraproject.org/tests/673553
ID: 673566  Test: x86_64 universal upgrade_2_server_domain_controller
URL: https://openqa.fedoraproject.org/tests/673566
ID: 673587  Test: x86_64 universal upgrade_server_domain_controller
URL: https://openqa.fedoraproject.org/tests/673587

Passed openQA tests: 170/181 (x86_64)

Installed system changes in test x86_64 Everything-boot-iso install_default: 
System load changed from 0.02 to 0.15
Previous test data: https://openqa.fedoraproject.org/tests/672159#downloads
Current test data: https://openqa.fedoraproject.org/tests/673497#downloads

Installed system changes in test x86_64 Workstation-live-iso 
install_default_upload: 
Used swap changed from 27 MiB to 19 MiB
System load changed from 0.73 to 1.34
Previous test data: https://openqa.fedoraproject.org/tests/672162#downloads
Current test data: https://openqa.fedoraproject.org/tests/673500#downloads

Installed system changes in test x86_64 Workstation-live-iso 
install_default@uefi: 
System load changed from 0.88 to 0.49
Previous test data: https://openqa.fedoraproject.org/tests/672164#downloads
Current test data: https://openqa.fedoraproject.org/tests/673502#downloads

Installed system changes in test x86_64 KDE-live-iso install_default_upload: 
System load changed from 1.46 to 1.63
Previous test data: https://openqa.fedoraproject.org/tests/672181#downloads
Current test data: https://openqa.fedoraproject.org/tests/673519#downloads

Installed system changes in test x86_64 Silverblue-dvd_ostree-iso 
install_default@uefi: 
System load changed from 0.53 to 0.31
Previous test data: https://openqa.fedoraproject.org/tests/672201#downloads
Current test data: https://openqa.fedoraproject.org/tests/673539#downloads

Installed system changes in test x86_64 universal install_package_set_kde: 
System load changed from 1.75 to 1.53
Previous test data: https://openqa.fedoraproject.org/tests/672242#downloads
Current test data: https://openqa.fedoraproject.org/tests/673580#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

Re: Orphaned packages looking for new maintainers

[Dan Čermák]

Miro Hrončok  writes:

> winetricksorphan, raphgro, tc010 weeks ago

Any particular reason why winetricks got orphaned?


Cheers,

Dan


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

Re: Fedora 33 - ssh clients - drop of PubkeyAcceptedKeyTypes=ssh-rsa

[José Abílio Matos]

On Monday, September 21, 2020 6:30:47 PM WEST Ankur Sinha wrote:
> I just updated to F33, and now I think I get the same issue with
> BitBucket.org:
> 
> $ ssh -Tv  g...@bitbucket.org
> ...
> send_pubkey_test: no mutual signature algorithm
> 
> It works if I use:
> 
> $ ssh -Tv -oPubkeyAcceptedKeyTypes=+ssh-rsa  g...@bitbucket.org
> 
> Github and Gitlab seem to work fine, so this is Bitbucket specific.

I hit that two week ago for bitbucket and other servers. In my case I got it 
connecting to lyx git server. At the time I wrote about it in the fedora-test 
mailing list.

My workaround solution was to add to ~/.ssh/config

Host *
  PubkeyAcceptedKeyTypes +rsa-sha2-256,rsa-sha2-512


That made the connections work again.
-- 
José Abílio___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Fedora 33 compose report: 20200921.n.0 changes

[Fedora Rawhide Report]

OLD: Fedora-33-20200920.n.0
NEW: Fedora-33-20200921.n.0

= SUMMARY =
Added images:0
Dropped images:  5
Added packages:  0
Dropped packages:0
Upgraded packages:   0
Downgraded packages: 0

Size of added packages:  0 B
Size of dropped packages:0 B
Size of upgraded packages:   0 B
Size of downgraded packages: 0 B

Size change of upgraded packages:   0 B
Size change of downgraded packages: 0 B

= ADDED IMAGES =

= DROPPED IMAGES =
Image: Minimal raw-xz aarch64
Path: Spins/aarch64/images/Fedora-Minimal-33-20200920.n.0.aarch64.raw.xz
Image: SoaS raw-xz armhfp
Path: Spins/armhfp/images/Fedora-SoaS-armhfp-33-20200920.n.0-sda.raw.xz
Image: Container_Minimal_Base docker aarch64
Path: 
Container/aarch64/images/Fedora-Container-Minimal-Base-33-20200920.n.0.aarch64.tar.xz
Image: Xfce raw-xz aarch64
Path: Spins/aarch64/images/Fedora-Xfce-33-20200920.n.0.aarch64.raw.xz
Image: Container_Base docker aarch64
Path: 
Container/aarch64/images/Fedora-Container-Base-33-20200920.n.0.aarch64.tar.xz

= ADDED PACKAGES =

= DROPPED PACKAGES =

= UPGRADED PACKAGES =

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

Re: Kubernetes Development SIG

[Breno Brand Fernandes]

I would like to be part too :)

- Breno

On Tue, 15 Sep 2020 at 11:46, Ankur Sinha  wrote:

> On Tue, Sep 15, 2020 20:25:18 +0530, Sumantro Mukherjee wrote:
> >
> >
> > On Tue, Sep 15, 2020 at 7:15 PM Leonardo Rossetti 
> wrote:
> >
> > Hello all,
> >
> > I would like to present a Kubernetes Development SIG.
> >
> > 
> > I would love to be a part of the group!
>
> +1, mostly as a user :)
>
> --
> Thanks,
> Regards,
> Ankur Sinha "FranciscoD" (He / Him / His) |
> https://fedoraproject.org/wiki/User:Ankursinha
> Time zone: Europe/London
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Conflicting build-ids in chromium and chromium-freeworld

[Marcin Zajączkowski]

On 2020-09-21 12:08, Mark Wielaard wrote:
> Hi,
> 
> On Mon, 2020-09-21 at 08:55 +0300, Panu Matilainen wrote:
>> On 9/21/20 12:25 AM, Marcin Zajączkowski wrote:
>>> Hi. There is an ongoing problem with conflicting build-ids in chromium
>>> and chromium-freeworld [1][2]:
 Error: Transaction test error:
file /usr/lib/.build-id/61/91aba223f60784c4a2fb95cdedcedc97217e5b from 
 install of chromium-freeworld-85.0.4183.102-1.fc32.x86_64 conflicts with 
 file from package chromium-85.0.4183.102-1.fc32.x86_64
file /usr/lib/.build-id/82/5827dc3adff19282b7b337b044b381e2f226ee from 
 install of chromium-freeworld-85.0.4183.102-1.fc32.x86_64 conflicts with 
 file from package chromium-85.0.4183.102-1.fc32.x86_64
file /usr/lib/.build-id/c1/a0a2a071572e46f4b3800bbb0f7ba217b42df7 from 
 install of chromium-freeworld-85.0.4183.102-1.fc32.x86_64 conflicts with 
 file from package chromium-85.0.4183.102-1.fc32.x86_64
file /usr/lib/.build-id/cc/2a382a1ab1ec74354adf012ad958a17f880f88 from 
 install of chromium-freeworld-85.0.4183.102-1.fc32.x86_64 conflicts with 
 file from package chromium-85.0.4183.102-1.fc32.x86_64
file /usr/lib/.build-id/d9/1c0feec7526201e135457e3a7f4ff4e4aebfea from 
 install of chromium-freeworld-85.0.4183.102-1.fc32.x86_64 conflicts with 
 file from package chromium-85.0.4183.102-1.fc32.x86_64
>>>
>>> There is no clear idea why it happens, but my assumption is that due to
>>> the fact of building with the same source code (with similar patches),
>>> some generated shared libraries are the same which generates conflict(s).
> 
> The error message could probably be improved.
> You might want to look at where the /usr/lib/.build-id/xx/ symlinks
> are pointing at to get a better idea which binaries are identical
> between the packages.
> 
>>> The quick look at the algorithm for build-id generation [3] doesn't
>>> answer my question what exactly is taken into account for their
>>> generation and more precisely is there is way to add some "fuzz" (having
>>> different buildroots doesn't help) to distinguish those libraries.
> 
> The build-id is calculated over all relevant build environment bits (by
> the linker, not rpm). This includes the debuginfo in the original (not
> split) ELF file. The debuginfo contains the build paths (which should
> be different for different NVRs and include the compiler version and
> flags). This really should prevent identical build-ids whenever
> something is really build from source. Normally you only get identical
> build-ids when building the same source code in the same package with
> the same compiler flags. Identical build-ids between packages are
> really very rare and are often caused by some binary blob simply being
> copied between packages (is there a blob in the upstream tar ball that
> isn't build from source?) or if debuginfo (-g) is missing.
> 
>>> To wrap up:
>>> 1. Is there a better way to deal with the aforementioned build-id
>>> conflicts than disable their generation on one side (with "%global
>>> _build_id_links none")?
>>
>> Instead of disabling entirely, you could tell rpm to put it all into 
>> -debuginfo packages (ie the original debuginfo layout). Which would 
>> still conflict, but fewer people are affected:
>>
>> %global _build_id_links alldebug
> 
> Yes, that is a much better workaround than using none.

It sounds very sensible :). Especially, as a workaround, in the
situation that solving issues with duplicated shared libraries between
packages was problematic.

Thanks you guys for suggestions.

Marcin




> 
>>> 2. Maybe my assumption about the same generated shared libraries is
>>> wrong and there is something else what can be done to fix the root problem?
>>
>> That's exactly the cause, build-id's are engineered to reproducably 
>> identify identical built objects, regardless of their location. Which 
>> causes conflicts when the house rules of not shipping multiple idental 
>> copies is broken (one might call this a feature).
> 
> Yes, I would call this a feature :)
> 
>> Short of unbundling the shared libraries, I guess a reasonable 
>> workaround would be patching them to include some identifier string 
>> based on the containing package name, which would cause them to have 
>> different build_ids.
> 
> If build from source and building with debuginfo that should already be
> the case because the build-id is calculated over the original debuginfo
> which contains the original (pre-debugedit) build paths, which should
> contain the package nvr in their name. So double check that things are
> build with -g.
> 
> Cheers,
> 
> Mark



-- 
https://blog.solidsoft.pl/ - Working code is not enough
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: 

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

[stan via devel]

Hi,

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

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

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

Thanks.

PS I'm copying devel in case this isn't a kernel issue, and also
because my posts to the kernel list just seem to disappear into the
ether.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 33 - ssh clients - drop of PubkeyAcceptedKeyTypes=ssh-rsa

[Ankur Sinha]

On Sun, Sep 20, 2020 19:11:29 +0200, Pavel Raiskup wrote:
> After upgrade of one of my servers to F33, I noticed that I can not ssh to
> one of my other servers running Debian 9 system (relatively freshly EOLed,
> I need to do something about it).  On F33 I always need to:
> 
>  $ ssh -oPubkeyAcceptedKeyTypes=+ssh-rsa user@debian-9-host
> 
> The changes in Fedora packages led me to:
> 
> https://gitlab.com/redhat-crypto/fedora-crypto-policies/-/commit/b298a9e1
> 
> Which led me to:
> 
> https://fedoraproject.org/wiki/Changes/StrongCryptoSettings2
> 
> I'm curious about the effects of the change.  It claims that RSA 2048 >= 
> should
> stay accepted by DEFAULT, and from what I can tell the host server key seems 
> to
> be RSA 2048 (at least that's what is generated by default on Debian 9):
> 
> $ ssh-keygen -l -f ssh_host_rsa_key.pub
> 2048 SHA256:<...> root@debian-9-host (RSA)
> 
> Can anyone translate to me if this is really expected or a bug?  Effect is 
> that
> Fedora 33 clients can not ssh to Debian 9 hosts by default (I'm not sure about
> the supported Debian 10, and the key quality there).
> 

I just updated to F33, and now I think I get the same issue with BitBucket.org:

$ ssh -Tv  g...@bitbucket.org
...
send_pubkey_test: no mutual signature algorithm

It works if I use:

$ ssh -Tv -oPubkeyAcceptedKeyTypes=+ssh-rsa  g...@bitbucket.org

Github and Gitlab seem to work fine, so this is Bitbucket specific.

-- 
Thanks,
Regards,
Ankur Sinha "FranciscoD" (He / Him / His) | 
https://fedoraproject.org/wiki/User:Ankursinha
Time zone: Europe/London


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

Re: Orphaned packages looking for new maintainers

[Michael J Gruber]

> The following packages are orphaned and will be retired when they
> are orphaned for six weeks, unless someone adopts them. If you know for sure
> that the package should be retired, please do so now with a proper reason:
> https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life

> rubygem-erubisorphan   0 weeks ago

I can fix this FTBFS, and I'll take the package just to keep the depending 
packages from getting into trouble for F33. But they should probably move to 
erubi (no 's') instead. Anyone is welcome to take this instead of myself ...
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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 EOL wrt new dist-git branches (and my confusion)

[Richard Shaw]

On Sun, Sep 20, 2020 at 1:47 PM Kevin Fenzi  wrote:

> > Tangent nit-pick... Once an update has been created for a branch, why not
> > at least allow it to go to stable? Seeing my packages stuck in testing
> for
> > eternity bothers my OCD until I push enough updates I don't see it
> anymore.
>
> We could push all the testing updates stable at the end... but...
> that means there would be a flood of changes of things that didn't meed
> testing requirements, and additionally we could never fix any problems
> that happen because of that.
>
> Perhaps it would be better to unpush all the pending ones at eol?
>

Well, what I envision is more of shutting down builds first, and then
updates later, more of a staged response instead of shutting everything
down at one time.

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

Fedora-IoT-34-20200921.0 compose check report

[Fedora compose checker]

No missing expected images.

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

Old soft failures (same test soft failed in Fedora-IoT-34-20200920.0):

ID: 673196  Test: x86_64 IoT-dvd_ostree-iso iot_clevis
URL: https://openqa.fedoraproject.org/tests/673196

Passed openQA tests: 15/16 (x86_64)

New passes (same test not passed in Fedora-IoT-34-20200920.0):

ID: 673207  Test: x86_64 IoT-dvd_ostree-iso iot_zezere_server
URL: https://openqa.fedoraproject.org/tests/673207
ID: 673210  Test: x86_64 IoT-dvd_ostree-iso iot_zezere_ignition
URL: https://openqa.fedoraproject.org/tests/673210

Installed system changes in test x86_64 IoT-dvd_ostree-iso 
install_default@uefi: 
System load changed from 0.15 to 0.29
Previous test data: https://openqa.fedoraproject.org/tests/672051#downloads
Current test data: https://openqa.fedoraproject.org/tests/673199#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

Orphaning "vtun"

[Gabriel L. Somlo]

The functionality offered by the vtun package has been completely
subsumed by openssh, since at least with version 8.0. I've switched
to using openssh, and no longer have the need and resources to take
care of vtun.

Free to a good home, or ready for retirement.

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

[EPEL-devel] Fedora EPEL 8 updates-testing report

[updates]

The following Fedora EPEL 8 Security updates need testing:
 Age  URL
  12  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-0214580ca4   
mbedtls-2.16.8-1.el8
  10  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-c5ced83bcc   
seamonkey-2.53.4-1.el8
   3  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-11f765300e   
singularity-3.6.3-1.el8
   3  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-17fdec3133   
zeromq-4.3.3-1.el8
   2  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-9720b9f379   
matio-1.5.18-1.el8
   1  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-b65eda12a7   
chromium-85.0.4183.102-1.el8


The following builds have been pushed to Fedora EPEL 8 updates-testing

erfa-1.7.1-1.el8
ocserv-1.1.1-1.el8
python-dateutils-0.6.8-3.el8

Details about builds:



 erfa-1.7.1-1.el8 (FEDORA-EPEL-2020-b732aca929)
 Essential Routines for Fundamental Astronomy

Update Information:

Contains version 20200721 of SOFA libraries

ChangeLog:

* Sun Sep 20 2020 Sergio Pascual  - 1.7.1-1
- New upstream version (1.7.1)




 ocserv-1.1.1-1.el8 (FEDORA-EPEL-2020-6dd81a74cf)
 OpenConnect SSL VPN server

Update Information:

Update to upstream 1.1.1 release

ChangeLog:

* Mon Sep 21 2020 Nikos Mavrogiannopoulos  - 
1.1.1-1
- Update to upstream 1.1.1 release




 python-dateutils-0.6.8-3.el8 (FEDORA-EPEL-2020-82b421ec2c)
 Various utilities for working with date and datetime objects

Update Information:

Rebuilt for https://fedoraproject.org/wiki/Fedora_33_Mass_Rebuild

ChangeLog:


References:

  [ 1 ] Bug #1880870 - python-dateutils: EL8 package missing
https://bugzilla.redhat.com/show_bug.cgi?id=1880870


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

[EPEL-devel] Fedora EPEL 7 updates-testing report

[updates]

The following Fedora EPEL 7 Security updates need testing:
 Age  URL
 768  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-3c9292b62d   
condor-8.6.11-1.el7
 508  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-bc0182548b   
bubblewrap-0.3.3-2.el7
  15  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-83bdeb2965   
ansible-2.9.13-1.el7
  12  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-f9a03b   
mbedtls-2.7.17-1.el7
  10  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-25e525a9ca   
seamonkey-2.53.4-1.el7
   5  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-918ad695f6   
proftpd-1.3.5e-10.el7
   5  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-d968abb383   
golang-1.15.2-1.el7
   4  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-0f3f88c479   
nginx-1.16.1-2.el7
   3  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-92064b5b2b   
singularity-3.6.3-1.el7
   2  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-6b04ee5c07   
libuv-1.39.0-1.el7
   2  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-e621d9ff68   
matio-1.5.18-1.el7
   1  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-dec199d5a2   
chromium-85.0.4183.102-1.el7


The following builds have been pushed to Fedora EPEL 7 updates-testing

erfa-1.7.1-1.el7
libprelude-5.2.0-2.el7

Details about builds:



 erfa-1.7.1-1.el7 (FEDORA-EPEL-2020-c2229c3b79)
 Essential Routines for Fundamental Astronomy

Update Information:

Contains version 20200721 of SOFA libraries

ChangeLog:

* Sun Sep 20 2020 Sergio Pascual  - 1.7.1-1
- New upstream version (1.7.1)




 libprelude-5.2.0-2.el7 (FEDORA-EPEL-2020-d1a19d6c90)
 Secure Connections between all Sensors and the Prelude Manager

Update Information:

Bump version 5.2

ChangeLog:

* Fri Sep 18 2020 Thomas Andrejak  - 5.2.0-2
- Clean libprelude-config
* Thu Sep 17 2020 Thomas Andrejak  - 5.2.0-1
- Bump version 5.2.0


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

[Bug 1880857] perl-Module-CoreList-5.20200920 is available

[bugzilla]

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



--- Comment #5 from Fedora Update System  ---
FEDORA-2020-64dc185f10 has been pushed to the Fedora 32 testing repository.
In short time you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing
--advisory=FEDORA-2020-64dc185f10`
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2020-64dc185f10

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information
on how to test updates.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1880859] perl-CPAN-Perl-Releases-5.20200920 is available

[bugzilla]

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



--- Comment #4 from Fedora Update System  ---
FEDORA-2020-a5b6a25059 has been pushed to the Fedora 32 testing repository.
In short time you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing
--advisory=FEDORA-2020-a5b6a25059`
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2020-a5b6a25059

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information
on how to test updates.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1880857] perl-Module-CoreList-5.20200920 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #4 from Fedora Update System  ---
FEDORA-2020-18b12f28fa has been pushed to the Fedora 31 testing repository.
In short time you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing
--advisory=FEDORA-2020-18b12f28fa`
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2020-18b12f28fa

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information
on how to test updates.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

Re: [HEADS-UP] libevent 2.1.12 with a soname bump is coming to Rawhide

[Michal Sekletar]

On Tue, Sep 15, 2020 at 11:17 AM Ondřej Lysoněk  wrote:

>
> Initial set:
> - avahi - needs to be bootstrapped
> - packages that I haven't been able to rebuild:
>   - community-mysql, libreswan, perl-Event-Lib, sems
> - other: addrwatch, ccnet, coturn, groonga, ladvd, libasr,
>   libverto, links, lldpd, memcached, mpris-scrobbler, nbd-runner,
>   nfs-utils, nsd, ntp, ocproxy, opensmtpd, pgbouncer, php-pecl-event,
>   php-pecl-http, pmix, remctl, scanssh, seafile, sslsplit,
>   sstp-client, suricata, tmate, tmux, trickle, unbound, uwsgi, zabbix
>
> After avahi is rebuilt, we can rebuild:
> 389-ds-base, fragments, fstrm, icecat, libcouchbase, lua-event,
> netatalk, qt5-qtwebengine, thrift, tor, transmission
>

Hi everyone,

I've just rebuilt avahi in the bootstrap configuration and final rebuilt
with bootstrap mode turned off is in progress.

https://koji.fedoraproject.org/koji/buildinfo?buildID=1613864
https://koji.fedoraproject.org/koji/taskinfo?taskID=51958298

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

[Bug 1880859] perl-CPAN-Perl-Releases-5.20200920 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #3 from Fedora Update System  ---
FEDORA-2020-55d695d27e has been pushed to the Fedora 31 testing repository.
In short time you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing
--advisory=FEDORA-2020-55d695d27e`
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2020-55d695d27e

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information
on how to test updates.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1880850] perl-libwww-perl-6.48 is available

[bugzilla]

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



--- Comment #3 from Fedora Update System  ---
FEDORA-2020-8d45246086 has been submitted as an update to Fedora 32.
https://bodhi.fedoraproject.org/updates/FEDORA-2020-8d45246086


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1880850] perl-libwww-perl-6.48 is available

[bugzilla]

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



--- Comment #4 from Fedora Update System  ---
FEDORA-2020-22f40ebe4d has been submitted as an update to Fedora 31.
https://bodhi.fedoraproject.org/updates/FEDORA-2020-22f40ebe4d


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1880850] perl-libwww-perl-6.48 is available

[bugzilla]

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



--- Comment #2 from Fedora Update System  ---
FEDORA-2020-b6ef4e92cc has been submitted as an update to Fedora 33.
https://bodhi.fedoraproject.org/updates/FEDORA-2020-b6ef4e92cc


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1880850] perl-libwww-perl-6.48 is available

[bugzilla]

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

Petr Pisar  changed:

   What|Removed |Added

 Status|ASSIGNED|MODIFIED
   Fixed In Version||perl-libwww-perl-6.48-1.fc3
   ||4



--- Comment #1 from Petr Pisar  ---
An enhancement release suitable for all Fedoras.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1880850] perl-libwww-perl-6.48 is available

[bugzilla]

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

Petr Pisar  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 CC|ppi...@redhat.com   |
   Doc Type|--- |If docs needed, set a value




-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

Logs from Open NeuroFedora Meeting: 1300 UTC on Monday, 21st September

[Ankur Sinha]

Hello everyone,

Here are the logs from today's meeting. The next meeting will be at the
same time in 2 weeks time, and will be chaired by @purusharths.

===
#fedora-neuro: NeuroFedora - 2020-09-21
===

Meeting started by FranciscoD at 13:06:14 UTC. The full logs are
available at
https://meetbot.fedoraproject.org/fedora-neuro/2020-09-21/neurofedora.2020-09-21-13.06.log.html

Meeting summary
---
* Agenda  (FranciscoD, 13:07:05)
  * New introductions and roll call  (FranciscoD, 13:07:12)
  * Tasks from last week's meeting  (FranciscoD, 13:07:19)
  * Open Pagure tickets  (FranciscoD, 13:07:24)
  * Open bugs  (FranciscoD, 13:07:28)
  * CompNeuro lab compose check  (FranciscoD, 13:07:34)
  * Neuroscience query of the week  (FranciscoD, 13:07:41)
  * Next meeting date/time/chair  (FranciscoD, 13:07:47)
  * Open floor  (FranciscoD, 13:07:51)

* New introductions and roll call  (FranciscoD, 13:08:26)
  * Please go: Name, FAS, Fedora activity, etc etc etc  (FranciscoD,
13:08:38)
  * Ankur Sinha (FranciscoD), ankursinha, (UTC +1), NeuroFedora,
packaging, lots of other random Fedora related tasks  (FranciscoD,
13:09:10)
  * Aniket Pradhan (MeWjOr), major (+5:30), packaging?  (MeWjOr,
13:10:41)
  * Purusharth Saxena, purusharths, UTC+5:30 did a little bit of
packaging?  (purusharths, 13:10:57)

* Tasks from last meeting  (FranciscoD, 13:15:07)
  * Logs from last meeting:

https://meetbot.fedoraproject.org/teams/neurofedora/neurofedora.2020-09-07-13.07.html
(FranciscoD, 13:15:17)
  * FranciscoD ping https://pagure.io/fedora-websites/issue/1013 for
updates: DONE: still waiting on reply so will need to ping/poke more
(FranciscoD, 13:15:43)
  * ACTION: FranciscoD ping https://pagure.io/fedora-websites/issue/1013
for updates again  (FranciscoD, 13:15:58)
  * MeWjOr file a tracker ticket for FOSDEM: DONE
https://pagure.io/neuro-sig/NeuroFedora/issue/392  (FranciscoD,
13:16:24)
  * FranciscoD fix libneurosim: PENDING: needs some more work
(FranciscoD, 13:17:00)
  * ACTION: FranciscoD fix libneurosim:
https://bugzilla.redhat.com/show_bug.cgi?id=1864029  (FranciscoD,
13:17:06)

* Open Pagure tickets  (FranciscoD, 13:17:57)
  * Tagged "next meeting":

https://pagure.io/neuro-sig/NeuroFedora/issues?status=Open=S%3A+Next+meeting
(FranciscoD, 13:18:05)
  * https://pagure.io/neuro-sig/NeuroFedora/issue/393 : Why are we
maintaining PEGTL?  (FranciscoD, 13:19:38)
  * ACTION: query -devel list for PEGTL ownership, orphan if no interest
(FranciscoD, 13:23:25)
  * https://pagure.io/neuro-sig/NeuroFedora/issue/318 : NeuroFedora
reading/listening list  (FranciscoD, 13:23:57)

* Open NeuroFedora bugs: https://tinyurl.com/neurofedora-bugs
  (FranciscoD, 13:25:29)
  * List of NeuroFedora bugs: https://tinyurl.com/neurofedora-bugs
(FranciscoD, 13:25:37)
  * if you login to RHBZ, you can also add it to your "links" by going
to preferences > saved searches  (FranciscoD, 13:26:35)
  * FTBFS: vrpn: https://bugzilla.redhat.com/show_bug.cgi?id=1865613
(FranciscoD, 13:28:09)
  * FTBFS: neurord: https://bugzilla.redhat.com/show_bug.cgi?id=1864190
(FranciscoD, 13:28:20)
  * vrpn: https://src.fedoraproject.org/rpms/vrpn  (FranciscoD,
13:29:38)
  * ACTION: FranciscoD ping primary vrpn maintainer, and remove
neuro-sig from package  (FranciscoD, 13:35:17)

* CompNeuro lab compose status check for F33/F34  (FranciscoD, 13:36:45)
  * LINK:

https://koji.fedoraproject.org/koji/search?match=glob=build=*Comp_Neuro*
(FranciscoD, 13:42:19)
  * Latest rawhide image:
https://koji.fedoraproject.org/koji/buildinfo?buildID=1613727
2020-09-21, so looks OK  (FranciscoD, 13:42:57)
  * Latest F33 image:
https://koji.fedoraproject.org/koji/buildinfo?buildID=1613550
2020-09-20, so also looks OK  (FranciscoD, 13:43:18)
  * Both F33 and F34 comp-neuro images are building fine  (FranciscoD,
13:43:39)
  * URL for images:

https://koji.fedoraproject.org/koji/search?match=glob=build=*Comp_Neuro*
(FranciscoD, 13:43:51)

* Neuroscience query of the week  (FranciscoD, 13:44:05)
  * LINK:
https://koji.fedoraproject.org/koji/packageinfo?packageID=30691
should also work  (gicmo, 13:44:20)
  * Better link for Comp-Neuro builds:
https://koji.fedoraproject.org/koji/packageinfo?packageID=30691
(FranciscoD, 13:45:14)
  * Image compose task is "livemedia" on koji  (FranciscoD, 13:46:03)

* Next meeting time and date, chair  (FranciscoD, 13:46:42)
  * purusharths chair next meeting, same time in two weeks  (FranciscoD,
13:47:56)
  * ACTION: FranciscoD send out logs  (FranciscoD, 13:48:31)

* Open floor  (FranciscoD, 13:48:52)
  * NWB user days is going on:
https://neurodatawithoutborders.github.io/nwb_hackathons/HCK09_2020_Remote/
(FranciscoD, 13:49:57)
  * OCNS Infra/tools/software SIG is taking off:

Re: In which order does ELN build packages, what build root is it using?

[Miro Hrončok]

On 21. 09. 20 15:40, Mark Wielaard wrote:

Hi,

I couldn't build elfutils because of an annobin bug that showed up on
ppc64le. Nick was nice enough to fix it and push a new annobin version:
https://bodhi.fedoraproject.org/updates/FEDORA-2020-c78fce452e
So I could build elfutils again:
https://bodhi.fedoraproject.org/updates/FEDORA-2020-06dafb46c1
But now I am getting notices about the ELN build failures:
https://koji.fedoraproject.org/koji/buildinfo?buildID=1613859
Which is clearly because it doesn't have the new annobin package.

In this case, the build fails, which is the better outcome.

However recently, I've rebuild redhat-rpm-config with this change:

  https://src.fedoraproject.org/rpms/redhat-rpm-config/c/0d621460

And later I've built python3.9 with the new macro to actually deliver the 
change.

In order to make it work, I've run:

  $ koji wait-repo f34-build --build=redhat-rpm-config-172-1.fc34
  $ koji wait-repo eln-build --build=redhat-rpm-config-172-1.eln103

before building python3.9 in rawhide.

But I wondered: In case I would have not run the ELN waitrepo, would ELN 
possibly rebuild python3.9 before the new redhat-rpm-config was available in the 
ELN buildroot?


--
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

Re: Fedora 33 - ssh clients - drop of PubkeyAcceptedKeyTypes=ssh-rsa

[Stephen John Smoogen]

On Sun, 20 Sep 2020 at 16:03, Pavel Raiskup  wrote:

> On Sunday, September 20, 2020 8:52:21 PM CEST Kevin Fenzi wrote:
> > On Sun, Sep 20, 2020 at 07:11:29PM +0200, Pavel Raiskup wrote:
> > > After upgrade of one of my servers to F33, I noticed that I can not
> ssh to
> > > one of my other servers running Debian 9 system (relatively freshly
> EOLed,
> > > I need to do something about it).  On F33 I always need to:
> > >
> > >  $ ssh -oPubkeyAcceptedKeyTypes=+ssh-rsa user@debian-9-host
> > >
> > > The changes in Fedora packages led me to:
> > >
> > >
> https://gitlab.com/redhat-crypto/fedora-crypto-policies/-/commit/b298a9e1
> > >
> > > Which led me to:
> > >
> > > https://fedoraproject.org/wiki/Changes/StrongCryptoSettings2
> > >
> > > I'm curious about the effects of the change.  It claims that RSA 2048
> >= should
> > > stay accepted by DEFAULT, and from what I can tell the host server key
> seems to
> > > be RSA 2048 (at least that's what is generated by default on Debian 9):
> > >
> > > $ ssh-keygen -l -f ssh_host_rsa_key.pub
> > > 2048 SHA256:<...> root@debian-9-host (RSA)
> > >
> > > Can anyone translate to me if this is really expected or a bug?
> Effect is that
> > > Fedora 33 clients can not ssh to Debian 9 hosts by default (I'm not
> sure about
> > > the supported Debian 10, and the key quality there).
> >
> > I thought this was actually due to openssh dropping support for
> > 'ssh-rsa':
> >
> > https://www.openssh.com/txt/release-8.3
> >
> > (ie, the sha-1 ssh-rsa)
>
> Well, I did:
>
> $ cd /etc/ssh
> $ rm ssh_host*
> $ ssh-keygen -N "" -t rsa-sha2-512 -b 4096 -f /etc/ssh/ssh_host_rsa_key
> $ dpkg-reconfigure openssh-server
> ... generates the remaining ECDSA and ED25519 ...
>
>
I would just double check that is the file being used for host keys and not
something been altered on the hosts /etc/ssh/sshd_config [I banged my head
on this recently so it is an off chance it might be the case.]


> New host signature detected, but I still get on F33 when trying to ssh:
>
> $ ssh -vv ...
> debug1: Offering public key: /home/praiskup/.ssh/id_rsa RSA SHA256:...
> debug1: send_pubkey_test: no mutual signature algorithm
> ...
>
> And still -oPubkeyAcceptedKeyTypes=+ssh-rsa helps...  Does that meant that
> the
> ssh-keygen on Debian 9 is broken?  How am I able to tell this is server or
> client problem?
>
> Pavel
>

sshd -d -p  on the server and then see what it is saying it is doing.

look for

debug1: kex_input_ext_info:
server-sig-algs=

or some similar item. also look to see what

grep KexAlgorithms /etc/ssh/sshd_config says

if it has a default of ssh-rsa in its list and none of the rsa-sha2 items..
the server will try this anyway.


-- 
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

In which order does ELN build packages, what build root is it using?

[Mark Wielaard]

Hi,

I couldn't build elfutils because of an annobin bug that showed up on
ppc64le. Nick was nice enough to fix it and push a new annobin version:
https://bodhi.fedoraproject.org/updates/FEDORA-2020-c78fce452e
So I could build elfutils again:
https://bodhi.fedoraproject.org/updates/FEDORA-2020-06dafb46c1
But now I am getting notices about the ELN build failures:
https://koji.fedoraproject.org/koji/buildinfo?buildID=1613859
Which is clearly because it doesn't have the new annobin package.

Is this something to worry about? Will ELN resync and re-try the build
automatically? Or do I somehow need to take action to get ELN buildroot
synced with fedora/rawhide again?

Thanks,

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

Re: F34 Change proposal: Wayland by Default for KDE Plasma Desktop (System-Wide Change)

[Neal Gompa]

On Mon, Sep 21, 2020 at 9:05 AM Vitaly Zaitsev via devel
 wrote:
>
> On 21.09.2020 14:30, Neal Gompa wrote:
> > Do you
> > seriously think that the bugs there won't get fixed? Some of them
> > already *have* been fixed in Plasma 5.19.
>
> A very annoying bug[1] with broken keyboard layout switcher must be a
> blocker. Not everyone here lives in English-speaking countries.
>
> [1]: https://bugs.kde.org/show_bug.cgi?id=390079

Yes, I know of it. My systems have multiple languages activated too.
It works right now, but the indicator telling you which mode you're in
is broken at the moment.




--
真実はいつも一つ！/ 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

Re: Orphaned packages looking for new maintainers

[Vít Ondruch]

Dne 21. 09. 20 v 14:39 Miro Hrončok napsal(a):
> The following packages are orphaned and will be retired when they
> are orphaned for six weeks, unless someone adopts them. If you know
> for sure
> that the package should be retired, please do so now with a proper
> reason:
> https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life
>
> Note: If you received this mail directly you (co)maintain one of the
> affected
> packages or a package that depends on one. Please adopt the affected
> package or
> retire your depending package to avoid broken dependencies, otherwise
> your
> package will be retired when the affected package gets retired.
>
> Request package ownership via the *Take* button in he left column on
> https://src.fedoraproject.org/rpms/
>
> Full report available at:
> https://churchyard.fedorapeople.org/orphans-2020-09-21.txt
> grep it for your FAS username and follow the dependency chain.
>
> For human readable dependency chains, see
> https://packager.fedorainfracloud.org/
> For all orphaned packages, see
> https://packager.fedorainfracloud.org/orphan
>
>     Package  (co)maintainers  
> Status Change
> 
>
>

... snip ...


> rubygem-erubis    orphan   0
> weeks ago


It seems that the dependency chain is quite huge and quite some
packagers are listed here. But there is fix for this issue proposed here:

https://src.fedoraproject.org/rpms/rubygem-asciidoctor/pull-request/4


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

Re: F34 Change proposal: Wayland by Default for KDE Plasma Desktop (System-Wide Change)

[Vitaly Zaitsev via devel]

On 21.09.2020 14:30, Neal Gompa wrote:
> Do you
> seriously think that the bugs there won't get fixed? Some of them
> already *have* been fixed in Plasma 5.19.

A very annoying bug[1] with broken keyboard layout switcher must be a
blocker. Not everyone here lives in English-speaking countries.

[1]: https://bugs.kde.org/show_bug.cgi?id=390079

-- 
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

Orphaned packages looking for new maintainers

[Miro Hrončok]

The following packages are orphaned and will be retired when they
are orphaned for six weeks, unless someone adopts them. If you know for sure
that the package should be retired, please do so now with a proper reason:
https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life

Note: If you received this mail directly you (co)maintain one of the affected
packages or a package that depends on one. Please adopt the affected package or
retire your depending package to avoid broken dependencies, otherwise your
package will be retired when the affected package gets retired.

Request package ownership via the *Take* button in he left column on
https://src.fedoraproject.org/rpms/

Full report available at:
https://churchyard.fedorapeople.org/orphans-2020-09-21.txt
grep it for your FAS username and follow the dependency chain.

For human readable dependency chains, see https://packager.fedorainfracloud.org/
For all orphaned packages, see https://packager.fedorainfracloud.org/orphan

Package  (co)maintainers   Status Change

apache-commons-dbcp   mizdebsk, orphan 5 weeks ago
fedora-icon-theme orphan   2 weeks ago
freight   orphan   2 weeks ago
geronimo-parent-poms  jjelen, mizdebsk, orphan 4 weeks ago
golang-github-mholt-  orphan   3 weeks ago
certmagic-0.9
jboss-interceptors-1.2-apiorphan   1 weeks ago
joda-time mizdebsk, orphan 5 weeks ago
jvnet-parent  mizdebsk, orphan 4 weeks ago
log4j12   mizdebsk, orphan 1 weeks ago
marble-widget orphan, rdieter  3 weeks ago
nodejs-babel-code-frame   orphan   2 weeks ago
nodejs-base   orphan   2 weeks ago
nodejs-bcrypt nodejs-sig, orphan   2 weeks ago
nodejs-body-parserorphan   2 weeks ago
nodejs-bufferutil nodejs-sig, orphan   2 weeks ago
nodejs-cache-base orphan   2 weeks ago
nodejs-call-matcher   orphan   2 weeks ago
nodejs-cross-spawnnodejs-sig, orphan   2 weeks ago
nodejs-cross-spawn-async  nodejs-sig, orphan   2 weeks ago
nodejs-css-stringify  nodejs-sig, orphan, patches  4 weeks ago
nodejs-css-tree   orphan   4 weeks ago
nodejs-doctrine   galileo, nodejs-sig, orphan, 2 weeks ago
  vjancik
nodejs-espower-location-  orphan   4 weeks ago
detector
nodejs-esrecurse  nodejs-sig, orphan   2 weeks ago
nodejs-faucet orphan   2 weeks ago
nodejs-fs-dot-notify  orphan   2 weeks ago
nodejs-gauge  nodejs-sig, orphan   2 weeks ago
nodejs-global-prefix  nodejs-sig, orphan   2 weeks ago
nodejs-grunt  nodejs-sig, orphan, patches, 4 weeks ago
  piotrp
nodejs-grunt-legacy-util  nodejs-sig, orphan, patches, 2 weeks ago
  piotrp
nodejs-http-signature nodejs-sig, orphan, patches  1 weeks ago
nodejs-jsonm  nodejs-sig, orphan   2 weeks ago
nodejs-jsonstream nodejs-sig, orphan   2 weeks ago
nodejs-markdown-it-testgennodejs-sig, orphan   2 weeks ago
nodejs-node-staticnodejs-sig, orphan, tdawson  1 weeks ago
nodejs-nopt   nodejs-sig, orphan, patches  1 weeks ago
nodejs-option-cache   orphan   2 weeks ago
nodejs-raw-body   nodejs-sig, orphan, patches  2 weeks ago
nodejs-rechoirnodejs-sig, orphan   2 weeks ago
nodejs-require-yaml   nodejs-sig, orphan   2 weeks ago
nodejs-rfile  orphan   2 weeks ago
nodejs-rollup-plugin-commonjs orphan   2 weeks ago
nodejs-rollup-plugin-node-orphan   2 weeks ago
resolve
nodejs-snapdragon orphan   4 weeks ago
nodejs-socket-dot-io-parser   orphan   2 weeks ago
nodejs-tap-mocha-reporter nodejs-sig, orphan   2 weeks ago
nodejs-tap-parser nodejs-sig, 

Orphaned packages looking for new maintainers

[Miro Hrončok]

The following packages are orphaned and will be retired when they
are orphaned for six weeks, unless someone adopts them. If you know for sure
that the package should be retired, please do so now with a proper reason:
https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life

Note: If you received this mail directly you (co)maintain one of the affected
packages or a package that depends on one. Please adopt the affected package or
retire your depending package to avoid broken dependencies, otherwise your
package will be retired when the affected package gets retired.

Request package ownership via the *Take* button in he left column on
https://src.fedoraproject.org/rpms/

Full report available at:
https://churchyard.fedorapeople.org/orphans-2020-09-21.txt
grep it for your FAS username and follow the dependency chain.

For human readable dependency chains, see https://packager.fedorainfracloud.org/
For all orphaned packages, see https://packager.fedorainfracloud.org/orphan

Package  (co)maintainers   Status Change

apache-commons-dbcp   mizdebsk, orphan 5 weeks ago
fedora-icon-theme orphan   2 weeks ago
freight   orphan   2 weeks ago
geronimo-parent-poms  jjelen, mizdebsk, orphan 4 weeks ago
golang-github-mholt-  orphan   3 weeks ago
certmagic-0.9
jboss-interceptors-1.2-apiorphan   1 weeks ago
joda-time mizdebsk, orphan 5 weeks ago
jvnet-parent  mizdebsk, orphan 4 weeks ago
log4j12   mizdebsk, orphan 1 weeks ago
marble-widget orphan, rdieter  3 weeks ago
nodejs-babel-code-frame   orphan   2 weeks ago
nodejs-base   orphan   2 weeks ago
nodejs-bcrypt nodejs-sig, orphan   2 weeks ago
nodejs-body-parserorphan   2 weeks ago
nodejs-bufferutil nodejs-sig, orphan   2 weeks ago
nodejs-cache-base orphan   2 weeks ago
nodejs-call-matcher   orphan   2 weeks ago
nodejs-cross-spawnnodejs-sig, orphan   2 weeks ago
nodejs-cross-spawn-async  nodejs-sig, orphan   2 weeks ago
nodejs-css-stringify  nodejs-sig, orphan, patches  4 weeks ago
nodejs-css-tree   orphan   4 weeks ago
nodejs-doctrine   galileo, nodejs-sig, orphan, 2 weeks ago
  vjancik
nodejs-espower-location-  orphan   4 weeks ago
detector
nodejs-esrecurse  nodejs-sig, orphan   2 weeks ago
nodejs-faucet orphan   2 weeks ago
nodejs-fs-dot-notify  orphan   2 weeks ago
nodejs-gauge  nodejs-sig, orphan   2 weeks ago
nodejs-global-prefix  nodejs-sig, orphan   2 weeks ago
nodejs-grunt  nodejs-sig, orphan, patches, 4 weeks ago
  piotrp
nodejs-grunt-legacy-util  nodejs-sig, orphan, patches, 2 weeks ago
  piotrp
nodejs-http-signature nodejs-sig, orphan, patches  1 weeks ago
nodejs-jsonm  nodejs-sig, orphan   2 weeks ago
nodejs-jsonstream nodejs-sig, orphan   2 weeks ago
nodejs-markdown-it-testgennodejs-sig, orphan   2 weeks ago
nodejs-node-staticnodejs-sig, orphan, tdawson  1 weeks ago
nodejs-nopt   nodejs-sig, orphan, patches  1 weeks ago
nodejs-option-cache   orphan   2 weeks ago
nodejs-raw-body   nodejs-sig, orphan, patches  2 weeks ago
nodejs-rechoirnodejs-sig, orphan   2 weeks ago
nodejs-require-yaml   nodejs-sig, orphan   2 weeks ago
nodejs-rfile  orphan   2 weeks ago
nodejs-rollup-plugin-commonjs orphan   2 weeks ago
nodejs-rollup-plugin-node-orphan   2 weeks ago
resolve
nodejs-snapdragon orphan   4 weeks ago
nodejs-socket-dot-io-parser   orphan   2 weeks ago
nodejs-tap-mocha-reporter nodejs-sig, orphan   2 weeks ago
nodejs-tap-parser nodejs-sig, 

Re: F34 Change proposal: Wayland by Default for KDE Plasma Desktop (System-Wide Change)

[Neal Gompa]

On Mon, Sep 21, 2020 at 8:28 AM Vitaly Zaitsev via devel
 wrote:
>
> On 21.09.2020 13:19, Neal Gompa wrote:
> > KDE upstream has a
> > specific "goal" to get Wayland support to first-class status:
> > https://community.kde.org/Goals/Wayland
>
> https://community.kde.org/Plasma/Wayland_Showstoppers
>

Okay, and? There's five months between now and beta freeze. Do you
seriously think that the bugs there won't get fixed? Some of them
already *have* been fixed in Plasma 5.19.



-- 
真実はいつも一つ！/ 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

Re: F34 Change proposal: Wayland by Default for KDE Plasma Desktop (System-Wide Change)

[Vitaly Zaitsev via devel]

On 21.09.2020 13:19, Neal Gompa wrote:
> KDE upstream has a
> specific "goal" to get Wayland support to first-class status:
> https://community.kde.org/Goals/Wayland

https://community.kde.org/Plasma/Wayland_Showstoppers

-- 
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

Re: protobuf (3.13) update is coming to rawhide

[Adrian Reber]

On Fri, Sep 18, 2020 at 08:23:40AM +0200, Adrian Reber wrote:
> I will do a protobuf update in rawhide which comes, as always, with a
> new SO version.
> 
> Before starting the builds in rawhide I will try it out first in COPR
> and once that is done I will do the builds in rawhide in a side tag.
> 
> repoquery gives me a list of 53 dependent packages I have to rebuild.

Most of the dependent packages did rebuilt without a problem. The
following 6 packages, however, did not rebuild successfully:

fawkes:
  /builddir/build/BUILD/fawkes-1.3.0/src/libs/protobuf_comm/peer.cpp: In member 
function 'void protobuf_comm::ProtobufBroadcastPeer::handle_resolve(const 
boost::system::error_code&, 
boost::asio::ip::basic_resolver::iterator)':
  /builddir/build/BUILD/fawkes-1.3.0/src/libs/protobuf_comm/peer.cpp:416:92: 
error: '_1' was not declared in this scope

cockatrice:
  
/builddir/build/BUILD/Cockatrice-2020-03-20-Release-2.7.4/cockatrice/src/replay_timeline_widget.cpp:
 In member function 'virtual void 
ReplayTimelineWidget::paintEvent(QPaintEvent*)':
  
/builddir/build/BUILD/Cockatrice-2020-03-20-Release-2.7.4/cockatrice/src/replay_timeline_widget.cpp:53:18:
 error: aggregate 'QPainterPath path' has incomplete type and cannot be defined

mir:
  In file included from 
../src/platforms/eglstream-kms/server/buffer_allocator.h:24,
 from ../src/platforms/eglstream-kms/server/platform.cpp:22:
  ../include/platform/mir/graphics/egl_extensions.h:105:9: error: 
'PFNEGLBINDWAYLANDDISPLAYWL' does not name a type
105 | PFNEGLBINDWAYLANDDISPLAYWL const eglBindWaylandDisplayWL;
| ^~
  ../include/platform/mir/graphics/egl_extensions.h:106:9: error: 
'PFNEGLQUERYWAYLANDBUFFERWL' does not name a type
106 | PFNEGLQUERYWAYLANDBUFFERWL const eglQueryWaylandBufferWL;
| ^~

tflogger:
  + /usr/bin/make -O -j2 V=1 VERBOSE=1
  make: *** No targets specified and no makefile found.  Stop.

community-mysql:
  Check of testcase failed for: x.resource_groups

  Completed: Failed 2/3880 tests, 99.95% were successful.

  Failing test(s): x.resource_groups

mapserver:
  + /usr/bin/make -O -j2 V=1 VERBOSE=1
  make: *** No targets specified and no makefile found.  Stop.


All logs can be found at: 
https://copr.fedorainfracloud.org/coprs/adrian/protobuf-3-13/builds/

I will start the rebuilds in the next days in a rawhide side tag.

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

[Florian Weimer]

* Aleksandra Fedorova:

> Hi, Florian,
>
> On Mon, Sep 21, 2020 at 11:35 AM Florian Weimer  wrote:
>>
>> How do side tag rebuilds and ELN interact?  If we do a complicated
>> synchronous package update in a side tag, will ELN track this closely?
>> Or will someone have to redo the same steps in ELN manually?
>
> For now we react on tagging events and process each "package is tagged
> to f34" koji event separately.
> For sidetags this means that we will try to rebuild all packages from
> the sidetag, but the order of rebuilds is not preserved.
>
> We are waiting for permissions to create sidetags for ELN in
> https://pagure.io/fedora-infrastructure/issue/9329
>
> Once it is available we will be setting up the automation for sidetag
> rebuilds in the same order as they were built for Rawhide.
> The work will be tracked by https://github.com/fedora-eln/eln/issues/2

Very nice.  Please stop before you've reimplemented MBS. 8-)

Thanks,
Florian
-- 
Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'Neill
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Side tag rebuilds an ELN

[Aleksandra Fedorova]

Hi, Florian,

On Mon, Sep 21, 2020 at 11:35 AM Florian Weimer  wrote:
>
> How do side tag rebuilds and ELN interact?  If we do a complicated
> synchronous package update in a side tag, will ELN track this closely?
> Or will someone have to redo the same steps in ELN manually?

For now we react on tagging events and process each "package is tagged
to f34" koji event separately.
For sidetags this means that we will try to rebuild all packages from
the sidetag, but the order of rebuilds is not preserved.

We are waiting for permissions to create sidetags for ELN in
https://pagure.io/fedora-infrastructure/issue/9329

Once it is available we will be setting up the automation for sidetag
rebuilds in the same order as they were built for Rawhide.
The work will be tracked by https://github.com/fedora-eln/eln/issues/2


> Thanks,
> Florian
> --
> Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn,
> Commercial register: Amtsgericht Muenchen, HRB 153243,
> Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael 
> O'Neill
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org



-- 

Aleksandra Fedorova
bookwar at #osci
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Conflicting build-ids in chromium and chromium-freeworld

[Nicolas Chauvet]

Le lun. 21 sept. 2020 à 12:08, Mark Wielaard  a écrit :
>
> Hi,
>
> On Mon, 2020-09-21 at 08:55 +0300, Panu Matilainen wrote:
> > On 9/21/20 12:25 AM, Marcin Zajączkowski wrote:
> > > Hi. There is an ongoing problem with conflicting build-ids in chromium
> > > and chromium-freeworld [1][2]:
> > > > Error: Transaction test error:
> > > >file /usr/lib/.build-id/61/91aba223f60784c4a2fb95cdedcedc97217e5b 
> > > > from install of chromium-freeworld-85.0.4183.102-1.fc32.x86_64 
> > > > conflicts with file from package chromium-85.0.4183.102-1.fc32.x86_64
> > > >file /usr/lib/.build-id/82/5827dc3adff19282b7b337b044b381e2f226ee 
> > > > from install of chromium-freeworld-85.0.4183.102-1.fc32.x86_64 
> > > > conflicts with file from package chromium-85.0.4183.102-1.fc32.x86_64
> > > >file /usr/lib/.build-id/c1/a0a2a071572e46f4b3800bbb0f7ba217b42df7 
> > > > from install of chromium-freeworld-85.0.4183.102-1.fc32.x86_64 
> > > > conflicts with file from package chromium-85.0.4183.102-1.fc32.x86_64
> > > >file /usr/lib/.build-id/cc/2a382a1ab1ec74354adf012ad958a17f880f88 
> > > > from install of chromium-freeworld-85.0.4183.102-1.fc32.x86_64 
> > > > conflicts with file from package chromium-85.0.4183.102-1.fc32.x86_64
> > > >file /usr/lib/.build-id/d9/1c0feec7526201e135457e3a7f4ff4e4aebfea 
> > > > from install of chromium-freeworld-85.0.4183.102-1.fc32.x86_64 
> > > > conflicts with file from package chromium-85.0.4183.102-1.fc32.x86_64
> > >
> > > There is no clear idea why it happens, but my assumption is that due to
> > > the fact of building with the same source code (with similar patches),
> > > some generated shared libraries are the same which generates conflict(s).
>
> The error message could probably be improved.
> You might want to look at where the /usr/lib/.build-id/xx/ symlinks
> are pointing at to get a better idea which binaries are identical
> between the packages.
>
> > > The quick look at the algorithm for build-id generation [3] doesn't
> > > answer my question what exactly is taken into account for their
> > > generation and more precisely is there is way to add some "fuzz" (having
> > > different buildroots doesn't help) to distinguish those libraries.
>
> The build-id is calculated over all relevant build environment bits (by
> the linker, not rpm). This includes the debuginfo in the original (not
> split) ELF file. The debuginfo contains the build paths (which should
> be different for different NVRs and include the compiler version and
> flags). This really should prevent identical build-ids whenever
> something is really build from source. Normally you only get identical
> build-ids when building the same source code in the same package with
> the same compiler flags. Identical build-ids between packages are
> really very rare and are often caused by some binary blob simply being
> copied between packages (is there a blob in the upstream tar ball that
> isn't build from source?) or if debuginfo (-g) is missing.


Hello Mark, thanks for confirming that case. (buildID conflict might
be caused by binaries not built from sources)

The suspected files are the following: (same for the fedora version).

lrwxrwxrwx. 1 root root 55 11 sept. 18:54
/usr/lib/.build-id/61/91aba223f60784c4a2fb95cdedcedc97217e5b ->
../../../../usr/lib64/chromium-freeworld/chrome-sandbox
lrwxrwxrwx. 1 root root 65 11 sept. 18:54
/usr/lib/.build-id/82/5827dc3adff19282b7b337b044b381e2f226ee ->
../../../../usr/lib64/chromium-freeworld/swiftshader/libGLESv2.so
lrwxrwxrwx. 1 root root 53 11 sept. 18:54
/usr/lib/.build-id/c1/a0a2a071572e46f4b3800bbb0f7ba217b42df7 ->
../../../../usr/lib64/chromium-freeworld/libGLESv2.so
lrwxrwxrwx. 1 root root 62 11 sept. 18:54
/usr/lib/.build-id/cc/2a382a1ab1ec74354adf012ad958a17f880f88 ->
../../../../usr/lib64/chromium-freeworld/swiftshader/libEGL.so
lrwxrwxrwx. 1 root root 50 11 sept. 18:54
/usr/lib/.build-id/d9/1c0feec7526201e135457e3a7f4ff4e4aebfea ->
../../../../usr/lib64/chromium-freeworld/libEGL.so

There is indeed a need to fix this on both sides.

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

Re: F34 Change proposal: Wayland by Default for KDE Plasma Desktop (System-Wide Change)

[Neal Gompa]

On Mon, Sep 21, 2020 at 7:11 AM Ondrej Mosnacek  wrote:
>
> On Mon, Sep 21, 2020 at 12:22 PM Pavel Raiskup  wrote:
> > On Thursday, September 10, 2020 6:00:09 PM CEST Ondrej Mosnacek wrote:
> > > On Thu, Sep 10, 2020 at 12:58 PM Neal Becker  wrote:
> > > > Might be interesting to try logging in as a new user to see if some 
> > > > older kde settings are messing things up.
> > >
> > > That's definitely possible... However this is a single-user machine
> > > and I don't really feel like creating a new user :)
> > >
> > > If I find some time I'll try it on my other laptop and/or dig deeper...
> >
> > Ondrej, what Fedora version are you on?  The change claims:
> >
> >   With KDE Plasma 5.20, the KDE Plasma desktop environment has reached a
> >   point where nearly all commonly used features in the desktop and all
> >   major applications function in the Plasma Wayland environment on all
> >   major GPUs (including NVIDIA with the proprietary driver).
> >
> > I'd consider a move to F34 just to test early, but even F34 still seems to
> > have 5.19.90.
>
> I was trying it on F32. I was ready to see various annoyances, since
> the proposal says that a lot of issues will be only fixed in F34, but
> I hoped that in F32 the desktop will at least look normal when I log
> in :)
>
> >
> > The change says:
> >
> >   How To Test
> >   ===
> >   Log into a KDE Plasma desktop. Do any activity you would normally do in
> >   your daily desktop use: launching applications, configuring displays,
> >   etc. Things should work the same way under Wayland as they used to
> >   under X.
> >
> > Even a simple link to step-by-step howto would help.  How much sense does
> > it have to test F32/F33?
>
> Probably not much :) I was just curious to see how good/bad the
> situation is currently on F32. From the optimistic wording in the
> change request I imagined that most things already work and the latest
> releases only fix some final annoyances... but maybe this is more true
> about F33 than F32, or I just have some weirdness in my existing
> configuration...
>

I'm personally running Plasma Wayland on a couple of computers now on
Plasma 5.18 on Fedora 32. To do so, all you need to do is install
"plasma-workspace-wayland" and select the "Plasma (Wayland) (Wayland)
(Wayland)" session (yes really, the text is fixed with Plasma 5.19)
from the SDDM drop down.

You'll be missing all the remaining "basic" features implemented into
kwin-wayland like middle click paste and screencasting support, but
those will become available with Plasma 5.20. KDE upstream has a
specific "goal" to get Wayland support to first-class status:
https://community.kde.org/Goals/Wayland

My desire is to activate it as default in Rawhide as soon as possible
and start working with KDE upstream to hammer things out throughout
the entire development cycle for Fedora 34. We will probably wind up
shipping Plasma 5.21 or Plasma 5.22 for Fedora 34 GA, and getting
testing and such going as early as possible will help get the actual
target release for Fedora 34 in good shape for Plasma Wayland.

But of course, if by the time we get to beta freeze and it's too
buggy, we'll flip the default back to Xorg while shipping both as
options on the media and try again for Fedora 35.


-- 
真実はいつも一つ！/ 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

Re: F34 Change proposal: Wayland by Default for KDE Plasma Desktop (System-Wide Change)

[Ondrej Mosnacek]

On Mon, Sep 21, 2020 at 12:22 PM Pavel Raiskup  wrote:
> On Thursday, September 10, 2020 6:00:09 PM CEST Ondrej Mosnacek wrote:
> > On Thu, Sep 10, 2020 at 12:58 PM Neal Becker  wrote:
> > > Might be interesting to try logging in as a new user to see if some older 
> > > kde settings are messing things up.
> >
> > That's definitely possible... However this is a single-user machine
> > and I don't really feel like creating a new user :)
> >
> > If I find some time I'll try it on my other laptop and/or dig deeper...
>
> Ondrej, what Fedora version are you on?  The change claims:
>
>   With KDE Plasma 5.20, the KDE Plasma desktop environment has reached a
>   point where nearly all commonly used features in the desktop and all
>   major applications function in the Plasma Wayland environment on all
>   major GPUs (including NVIDIA with the proprietary driver).
>
> I'd consider a move to F34 just to test early, but even F34 still seems to
> have 5.19.90.

I was trying it on F32. I was ready to see various annoyances, since
the proposal says that a lot of issues will be only fixed in F34, but
I hoped that in F32 the desktop will at least look normal when I log
in :)

>
> The change says:
>
>   How To Test
>   ===
>   Log into a KDE Plasma desktop. Do any activity you would normally do in
>   your daily desktop use: launching applications, configuring displays,
>   etc. Things should work the same way under Wayland as they used to
>   under X.
>
> Even a simple link to step-by-step howto would help.  How much sense does
> it have to test F32/F33?

Probably not much :) I was just curious to see how good/bad the
situation is currently on F32. From the optimistic wording in the
change request I imagined that most things already work and the latest
releases only fix some final annoyances... but maybe this is more true
about F33 than F32, or I just have some weirdness in my existing
configuration...

-- 
Ondrej Mosnacek
Software Engineer, Platform Security - SELinux kernel
Red Hat, Inc.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Fedora-Rawhide-20200921.n.0 compose check report

[Fedora compose checker]

No missing expected images.

Compose FAILS proposed Rawhide gating check!
3 of 43 required tests failed, 4 results missing
openQA tests matching unsatisfied gating requirements shown with **GATING** 
below

Failed openQA tests: 8/181 (x86_64)

Old failures (same test failed in Fedora-Rawhide-20200920.n.0):

ID: 672731  Test: x86_64 KDE-live-iso desktop_notifications_live
URL: https://openqa.fedoraproject.org/tests/672731
ID: 672754  Test: x86_64 Silverblue-dvd_ostree-iso release_identification
URL: https://openqa.fedoraproject.org/tests/672754
ID: 672790  Test: x86_64 universal install_blivet_resize_lvm
URL: https://openqa.fedoraproject.org/tests/672790
ID: 672815  Test: x86_64 universal install_cyrillic_language
URL: https://openqa.fedoraproject.org/tests/672815
ID: 672849  Test: x86_64 universal install_iscsi
URL: https://openqa.fedoraproject.org/tests/672849
ID: 672850  Test: x86_64 KDE-live-iso install_default_upload **GATING**
URL: https://openqa.fedoraproject.org/tests/672850
ID: 672866  Test: x86_64 KDE-live-iso install_no_user **GATING**
URL: https://openqa.fedoraproject.org/tests/672866
ID: 672867  Test: x86_64 KDE-live-iso install_default@uefi **GATING**
URL: https://openqa.fedoraproject.org/tests/672867

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

New soft failures (same test not soft failed in Fedora-Rawhide-20200920.n.0):

ID: 672730  Test: x86_64 Workstation-live-iso desktop_printing
URL: https://openqa.fedoraproject.org/tests/672730

Old soft failures (same test soft failed in Fedora-Rawhide-20200920.n.0):

ID: 672717  Test: x86_64 Workstation-live-iso desktop_update_graphical
URL: https://openqa.fedoraproject.org/tests/672717
ID: 672750  Test: x86_64 Silverblue-dvd_ostree-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/672750
ID: 672753  Test: x86_64 Silverblue-dvd_ostree-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/672753
ID: 672767  Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud
URL: https://openqa.fedoraproject.org/tests/672767
ID: 672780  Test: x86_64 universal upgrade_2_server_domain_controller
URL: https://openqa.fedoraproject.org/tests/672780
ID: 672801  Test: x86_64 universal upgrade_server_domain_controller
URL: https://openqa.fedoraproject.org/tests/672801

Passed openQA tests: 151/181 (x86_64)

New passes (same test not passed in Fedora-Rawhide-20200920.n.0):

ID: 672671  Test: x86_64 Server-dvd-iso install_vncconnect_client
URL: https://openqa.fedoraproject.org/tests/672671
ID: 672678  Test: x86_64 Server-dvd-iso install_vnc_server
URL: https://openqa.fedoraproject.org/tests/672678
ID: 672690  Test: x86_64 Server-dvd-iso install_vnc_client
URL: https://openqa.fedoraproject.org/tests/672690

Skipped gating openQA tests: 4/181 (x86_64)

Old skipped gating tests (same test skipped in Fedora-Rawhide-20200920.n.0):

ID: 672853  Test: x86_64 KDE-live-iso base_system_logging **GATING**
URL: https://openqa.fedoraproject.org/tests/672853
ID: 672854  Test: x86_64 KDE-live-iso base_update_cli **GATING**
URL: https://openqa.fedoraproject.org/tests/672854
ID: 672863  Test: x86_64 KDE-live-iso desktop_browser **GATING**
URL: https://openqa.fedoraproject.org/tests/672863
ID: 672865  Test: x86_64 KDE-live-iso desktop_terminal **GATING**
URL: https://openqa.fedoraproject.org/tests/672865

Skipped non-gating openQA tests: 11 of 181

Installed system changes in test x86_64 Server-dvd-iso install_default@uefi: 
System load changed from 0.09 to 0.23
Previous test data: https://openqa.fedoraproject.org/tests/671798#downloads
Current test data: https://openqa.fedoraproject.org/tests/672679#downloads

Installed system changes in test x86_64 Server-dvd-iso install_default_upload: 
System load changed from 0.17 to 0.47
Previous test data: https://openqa.fedoraproject.org/tests/671800#downloads
Current test data: https://openqa.fedoraproject.org/tests/672681#downloads

Installed system changes in test x86_64 Everything-boot-iso install_default: 
System load changed from 0.20 to 0.09
Previous test data: https://openqa.fedoraproject.org/tests/671830#downloads
Current test data: https://openqa.fedoraproject.org/tests/672711#downloads

Installed system changes in test x86_64 Everything-boot-iso 
install_default@uefi: 
System load changed from 0.04 to 0.30
Previous test data: https://openqa.fedoraproject.org/tests/671831#downloads
Current test data: https://openqa.fedoraproject.org/tests/672712#downloads

Installed system changes in test x86_64 Workstation-live-iso 
install_default_upload: 
System load changed from 1.30 to 1.02
Previous test data: https://openqa.fedoraproject.org/tests/671833#downloads
Current test data: https://openqa.fedoraproject.org/tests/672714#downloads

Installed system changes in test x86_64 Silverblue-dvd_ostree-iso 
install_default_upload: 
Used mem changed from 748 

Fedora-Cloud-31-20200921.0 compose check report

[Fedora compose checker]

No missing expected images.

Passed openQA tests: 7/7 (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

Re: Next Open NeuroFedora Meeting: 1300 UTC on Monday, 21st September

[Ankur Sinha]

Hi everyone,

A quick reminder of today's NeuroFedora SIG meeting. Please see below
for details. I hope to see you there.

On Fri, Sep 18, 2020 13:47:23 +0100, Ankur Sinha wrote:
> Hello everyone,
> 
> Please join us at the next Open NeuroFedora team meeting next week on
> Monday 21 September at 1300UTC in #fedora-neuro on IRC (Freenode). The
> meeting is a public meeting, and open for everyone to attend.
> 
> https://webchat.freenode.net/?channels=#fedora-neuro
> 
> The channel is 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 next Mon'
> 
> or you can use this link:
> https://www.timeanddate.com/worldclock/fixedtime.html?msg=NeuroFedora+Meeting=20200921T13=1440=1
> 
> The meeting will be chaired by @ankursinha. The agenda for the meeting
> is:
> 
> - New introductions and roll call.
> - Tasks from last week's meeting:
>   
> https://meetbot.fedoraproject.org/teams/neurofedora/neurofedora.2020-09-07-13.07.html
> - Open Pagure tickets:
>   
> https://pagure.io/neuro-sig/NeuroFedora/issues?status=Open=S%3A+Next+meeting
> - Open bugs check: https://tinyurl.com/neurofedora-bugs
> - CompNeuro lab compose status check for F33/F34.
> - 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,
> Ankur Sinha "FranciscoD" (He / Him / His) | 
> https://fedoraproject.org/wiki/User:Ankursinha
> Time zone: Europe/London



-- 
Thanks,
Regards,
Ankur Sinha "FranciscoD" (He / Him / His) | 
https://fedoraproject.org/wiki/User:Ankursinha
Time zone: Europe/London


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

Re: F34 Change proposal: Wayland by Default for KDE Plasma Desktop (System-Wide Change)

[Pavel Raiskup]

On Thursday, September 10, 2020 6:00:09 PM CEST Ondrej Mosnacek wrote:
> On Thu, Sep 10, 2020 at 12:58 PM Neal Becker  wrote:
> > Might be interesting to try logging in as a new user to see if some older 
> > kde settings are messing things up.
> 
> That's definitely possible... However this is a single-user machine
> and I don't really feel like creating a new user :)
> 
> If I find some time I'll try it on my other laptop and/or dig deeper...

Ondrej, what Fedora version are you on?  The change claims:

  With KDE Plasma 5.20, the KDE Plasma desktop environment has reached a
  point where nearly all commonly used features in the desktop and all
  major applications function in the Plasma Wayland environment on all
  major GPUs (including NVIDIA with the proprietary driver).

I'd consider a move to F34 just to test early, but even F34 still seems to
have 5.19.90.

The change says:

  How To Test
  ===
  Log into a KDE Plasma desktop. Do any activity you would normally do in
  your daily desktop use: launching applications, configuring displays,
  etc. Things should work the same way under Wayland as they used to
  under X.

Even a simple link to step-by-step howto would help.  How much sense does
it have to test F32/F33?

Pavel


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

Fedora rawhide compose report: 20200921.n.0 changes

[Fedora Rawhide Report]

OLD: Fedora-Rawhide-20200920.n.0
NEW: Fedora-Rawhide-20200921.n.0

= SUMMARY =
Added images:1
Dropped images:  0
Added packages:  0
Dropped packages:0
Upgraded packages:   47
Downgraded packages: 0

Size of added packages:  0 B
Size of dropped packages:0 B
Size of upgraded packages:   302.21 MiB
Size of downgraded packages: 0 B

Size change of upgraded packages:   -5.47 MiB
Size change of downgraded packages: 0 B

= ADDED IMAGES =
Image: Cinnamon live x86_64
Path: Spins/x86_64/iso/Fedora-Cinnamon-Live-x86_64-Rawhide-20200921.n.0.iso

= DROPPED IMAGES =

= ADDED PACKAGES =

= DROPPED PACKAGES =

= UPGRADED PACKAGES =
Package:  InsightToolkit-4.13.3-2.fc34
Old package:  InsightToolkit-4.13.3-1.fc34
Summary:  Insight Toolkit library for medical image processing
RPMs: InsightToolkit InsightToolkit-devel InsightToolkit-doc 
InsightToolkit-examples InsightToolkit-vtk InsightToolkit-vtk-devel
Size: 77.18 MiB
Size change:  12.97 KiB
Changelog:
  * Thu Aug 27 2020 I??aki ??car  - 4.13.3-2
  - https://fedoraproject.org/wiki/Changes/FlexiBLAS_as_BLAS/LAPACK_manager


Package:  azote-1.7.15-1.fc34
Old package:  azote-1.7.14-1.fc34
Summary:  Wallpaper and colour manager for Sway, i3 and some other WMs
RPMs: azote
Size: 643.67 KiB
Size change:  154 B
Changelog:
  * Sun Sep 20 2020 Bob Hepple  - 1.7.15-1
  - new version


Package:  bpytop-1.0.35-1.fc34
Old package:  bpytop-1.0.33-1.fc34
Summary:  Linux/OSX/FreeBSD resource monitor
RPMs: bpytop
Size: 62.96 KiB
Size change:  648 B
Changelog:
  * Sun Sep 20 2020 Artem Polishchuk  - 1.0.35-1
  - Update to 1.0.35


Package:  cjs-1:4.6.0-3.fc34
Old package:  cjs-1:4.6.0-2.fc33
Summary:  Javascript Bindings for Cinnamon
RPMs: cjs cjs-devel cjs-tests
Size: 3.44 MiB
Size change:  660.65 KiB
Changelog:
  * Sun Sep 20 2020 Leigh Scott  - 1:4.6.0-3
  - Use mozjs78 for f34+


Package:  dokuwiki-20200729-2.fc34
Old package:  dokuwiki-20200729-1.fc34
Summary:  Standards compliant simple to use wiki
RPMs: dokuwiki dokuwiki-selinux
Size: 2.23 MiB
Size change:  946 B
Changelog:
  * Sun Sep 20 2020 Artur Frenszek-Iwicki  - 20200729-2
  - Switch to requiring php-email-address-validation via php-composer()
  - Add a minimum version requirement on php-email-address-validation


Package:  drawing-0.6.0-1.fc34
Old package:  drawing-0.4.14-1.fc34
Summary:  Drawing application for the GNOME desktop
RPMs: drawing
Size: 2.38 MiB
Size change:  1.36 MiB
Changelog:
  * Sun Sep 20 2020 Artem Polishchuk  - 0.6.0-1
  - Update to 0.6.0


Package:  dummy-test-package-crested-0-1603
Old package:  dummy-test-package-crested-0-1599
Summary:  Dummy Test Package called Crested
RPMs: dummy-test-package-crested
Size: 105.74 KiB
Size change:  228 B
Changelog:
  * Sun Sep 20 2020 packagerbot  - 0-1600
  - rebuilt

  * Sun Sep 20 2020 packagerbot  - 0-1601
  - rebuilt

  * Sun Sep 20 2020 packagerbot  - 0-1602
  - rebuilt

  * Sun Sep 20 2020 packagerbot  - 0-1603
  - rebuilt


Package:  dummy-test-package-gloster-0-1473.fc34
Old package:  dummy-test-package-gloster-0-1465.fc34
Summary:  Dummy Test Package called Gloster
RPMs: dummy-test-package-gloster
Size: 96.66 KiB
Size change:  491 B
Changelog:
  * Sun Sep 20 2020 packagerbot  - 0-1466
  - rebuilt

  * Sun Sep 20 2020 packagerbot  - 0-1467
  - rebuilt

  * Sun Sep 20 2020 packagerbot  - 0-1468
  - rebuilt

  * Sun Sep 20 2020 packagerbot  - 0-1469
  - rebuilt

  * Sun Sep 20 2020 packagerbot  - 0-1470
  - rebuilt

  * Sun Sep 20 2020 packagerbot  - 0-1471
  - rebuilt

  * Mon Sep 21 2020 packagerbot  - 0-1472
  - rebuilt

  * Mon Sep 21 2020 packagerbot  - 0-1473
  - rebuilt


Package:  dummy-test-package-rubino-0-1603
Old package:  dummy-test-package-rubino-0-1599
Summary:  Dummy Test Package called Rubino
RPMs: dummy-test-package-rubino
Size: 105.87 KiB
Size change:  238 B
Changelog:
  * Sun Sep 20 2020 packagerbot  - 0-1600
  - rebuilt

  * Sun Sep 20 2020 packagerbot  - 0-1601
  - rebuilt

  * Sun Sep 20 2020 packagerbot  - 0-1602
  - rebuilt

  * Sun Sep 20 2020 packagerbot  - 0-1603
  - rebuilt


Package:  erfa-1.7.1-1.fc34
Old package:  erfa-1.7.0-3.fc33
Summary:  Essential Routines for Fundamental Astronomy
RPMs: erfa erfa-devel
Size: 959.04 KiB
Size change:  -4.65 KiB

Package:  fedmsg-1.1.2-1.fc34
Old package:  fedmsg-1.1.1-11.fc33
Summary:  Tools for Fedora Infrastructure real-time messaging
RPMs: fedmsg fedmsg-base fedmsg-doc python3-fedmsg
Size: 612.77 KiB
Size change:  6.85 KiB
Changelog:
  * Sun Sep 20 2020 Kevin Fenzi  - 1.1.2-1
  - Update to 1.1.2. Fixes 1880772


Package:  flameshot-0.8.0-1.fc34
Old package:  flameshot-0.6.0-6.fc33
Summary:  Powerful and simple to use screenshot software
RPMs

Re: Conflicting build-ids in chromium and chromium-freeworld

[Mark Wielaard]

Hi,

On Mon, 2020-09-21 at 08:55 +0300, Panu Matilainen wrote:
> On 9/21/20 12:25 AM, Marcin Zajączkowski wrote:
> > Hi. There is an ongoing problem with conflicting build-ids in chromium
> > and chromium-freeworld [1][2]:
> > > Error: Transaction test error:
> > >file /usr/lib/.build-id/61/91aba223f60784c4a2fb95cdedcedc97217e5b from 
> > > install of chromium-freeworld-85.0.4183.102-1.fc32.x86_64 conflicts with 
> > > file from package chromium-85.0.4183.102-1.fc32.x86_64
> > >file /usr/lib/.build-id/82/5827dc3adff19282b7b337b044b381e2f226ee from 
> > > install of chromium-freeworld-85.0.4183.102-1.fc32.x86_64 conflicts with 
> > > file from package chromium-85.0.4183.102-1.fc32.x86_64
> > >file /usr/lib/.build-id/c1/a0a2a071572e46f4b3800bbb0f7ba217b42df7 from 
> > > install of chromium-freeworld-85.0.4183.102-1.fc32.x86_64 conflicts with 
> > > file from package chromium-85.0.4183.102-1.fc32.x86_64
> > >file /usr/lib/.build-id/cc/2a382a1ab1ec74354adf012ad958a17f880f88 from 
> > > install of chromium-freeworld-85.0.4183.102-1.fc32.x86_64 conflicts with 
> > > file from package chromium-85.0.4183.102-1.fc32.x86_64
> > >file /usr/lib/.build-id/d9/1c0feec7526201e135457e3a7f4ff4e4aebfea from 
> > > install of chromium-freeworld-85.0.4183.102-1.fc32.x86_64 conflicts with 
> > > file from package chromium-85.0.4183.102-1.fc32.x86_64
> > 
> > There is no clear idea why it happens, but my assumption is that due to
> > the fact of building with the same source code (with similar patches),
> > some generated shared libraries are the same which generates conflict(s).

The error message could probably be improved.
You might want to look at where the /usr/lib/.build-id/xx/ symlinks
are pointing at to get a better idea which binaries are identical
between the packages.

> > The quick look at the algorithm for build-id generation [3] doesn't
> > answer my question what exactly is taken into account for their
> > generation and more precisely is there is way to add some "fuzz" (having
> > different buildroots doesn't help) to distinguish those libraries.

The build-id is calculated over all relevant build environment bits (by
the linker, not rpm). This includes the debuginfo in the original (not
split) ELF file. The debuginfo contains the build paths (which should
be different for different NVRs and include the compiler version and
flags). This really should prevent identical build-ids whenever
something is really build from source. Normally you only get identical
build-ids when building the same source code in the same package with
the same compiler flags. Identical build-ids between packages are
really very rare and are often caused by some binary blob simply being
copied between packages (is there a blob in the upstream tar ball that
isn't build from source?) or if debuginfo (-g) is missing.

> > To wrap up:
> > 1. Is there a better way to deal with the aforementioned build-id
> > conflicts than disable their generation on one side (with "%global
> > _build_id_links none")?
> 
> Instead of disabling entirely, you could tell rpm to put it all into 
> -debuginfo packages (ie the original debuginfo layout). Which would 
> still conflict, but fewer people are affected:
> 
> %global _build_id_links alldebug

Yes, that is a much better workaround than using none.

> > 2. Maybe my assumption about the same generated shared libraries is
> > wrong and there is something else what can be done to fix the root problem?
> 
> That's exactly the cause, build-id's are engineered to reproducably 
> identify identical built objects, regardless of their location. Which 
> causes conflicts when the house rules of not shipping multiple idental 
> copies is broken (one might call this a feature).

Yes, I would call this a feature :)

> Short of unbundling the shared libraries, I guess a reasonable 
> workaround would be patching them to include some identifier string 
> based on the containing package name, which would cause them to have 
> different build_ids.

If build from source and building with debuginfo that should already be
the case because the build-id is calculated over the original debuginfo
which contains the original (pre-debugedit) build paths, which should
contain the package nvr in their name. So double check that things are
build with -g.

Cheers,

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

Side tag rebuilds an ELN

[Florian Weimer]

How do side tag rebuilds and ELN interact?  If we do a complicated
synchronous package update in a side tag, will ELN track this closely?
Or will someone have to redo the same steps in ELN manually?

Thanks,
Florian
-- 
Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'Neill
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Copr package build fails on python-nocaselist package

[Andreas R Maier]

> Please consider reporting this against rpkg-util:
> https://pagure.io/rpkg-util 

I just created https://pagure.io/rpkg-util/issue/28 


Andy

> Begin forwarded message:
> 
> From: Pavel Raiskup 
> Subject: Re: Fwd: Copr package build fails on python-nocaselist package
> Date: 21. September 2020 at 10:26:42 CEST
> To: devel@lists.fedoraproject.org
> Cc: clime , Robert-André Mauchin 
> , Andreas R Maier 
> Reply-To: Development discussions related to Fedora 
> 
> 
> On Monday, September 21, 2020 9:07:32 AM CEST Andreas R Maier wrote:
>> Hello Robert,
>> I suspect the reason I get the python-%{srcname}-%{version} in the .tar.gz
>> file is that I was setting up COPR to use "rpkg". When using "copr-cli build"
>> as shown in your mail, it works on COPR. So I think we can ignore that issue.
> 
> Please consider reporting this against rpkg-util:
> https://pagure.io/rpkg-util 
> 
> Pavel
> 
>> At this point, I can successfully build locally (with "rpmbuild -bb"), on 
>> Koji (with "koji build"), and on COPR (with "copr-cli build").
>> 
>> I cannot yet build locally with "fedpkg mockbuild" or on Koji with "fedpkg 
>> scratch-build", and I suspect this is because there is no repo for the 
>> package yet and/or because I have not set up the mock environment on my 
>> local Fedora.
>> 
>> What I still don't understand is the package name: "rpmbuild -bs" creates an 
>> SRPM with package name "python3-nocaselist" while "fedpkg srpm" creates an 
>> SRPM with package name "python-nocaselist". What will be the package name in 
>> Fedora at the end of the day?
>> 
>> Andy
>> 
>>> Begin forwarded message:
>>> 
>>> From: Robert-André Mauchin 
>>> Subject: Re: Copr package build fails on python-nocaselist package
>>> Date: 18. September 2020 at 13:46:53 CEST
>>> To: Development discussions related to Fedora 
>>> 
>>> Reply-To: Development discussions related to Fedora 
>>> 
>>> 
>>> The archives in your SRPM are different:
>>> - on COPR the root directory of your archive is 
>>> python-%{srcname}-%{version} 
>>> - on Koji the root directory of your archive is %{srcname}-%{version}
>>> 
>>> Check that you have deleted python-%{srcname}-%{version}.tar.gz before 
>>> regenerating the SRPM.
>>> 
>>> Also I never use rpmbuild anymore, I do everything in the same directory 
>>> with 
>>> fedpkg:
>>> 
>>> ## Building the Fedora package
>>> 
>>> ### Build the source RPM locally:
>>> 
>>>   rm *.tar.gz *src.rpm
>>>   spectool -g *.spec && fedpkg --release f34 srpm
>>> 
>>> ### Build the binary RPM locally in a mock chroot:
>>> 
>>>   fedpkg --release f34  mockbuild --mock-config fedora-rawhide-x86_64 -N
>>> 
>>> Build logs and RPMs (if any) are in the results subdirectory
>>> 
>>> ### Build the binary RPM with the Koji build system:
>>> 
>>>   fedpkg  --release f34 scratch-build --srpm --fail-fast
>>> 
>>> ### COPR:
>>> 
>>>   copr-cli build python-nocaselist *.src.rpm
>>> 
>>> 
>>> 
>>> No idea where python-%{srcname}-%{version} in the .tar.gz is coming from, 
>>> neither pypi or github have that archive. Maybe it's an artifact of 
>>> building 
>>> the SRPM with rpkg?
>>> 
>>> ___
>>> devel mailing list -- devel@lists.fedoraproject.org
>>> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>>> Fedora Code of Conduct: 
>>> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>>> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>>> List Archives: 
>>> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>> 
>> 
> 
> 
> 
> ___
> devel mailing list -- devel@lists.fedoraproject.org 
> 
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org 
> 
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/ 
> 
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines 
> 
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org 
> 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Fedora-Cloud-32-20200921.0 compose check report

[Fedora compose checker]

No missing expected images.

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

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

ID: 672668  Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud
URL: https://openqa.fedoraproject.org/tests/672668

Passed openQA tests: 6/7 (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

[Bug 1880857] perl-Module-CoreList-5.20200920 is available

[bugzilla]

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



--- Comment #1 from Fedora Update System  ---
FEDORA-2020-ef530c53af has been submitted as an update to Fedora 33.
https://bodhi.fedoraproject.org/updates/FEDORA-2020-ef530c53af


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1880857] perl-Module-CoreList-5.20200920 is available

[bugzilla]

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



--- Comment #1 from Fedora Update System  ---
FEDORA-2020-ef530c53af has been submitted as an update to Fedora 33.
https://bodhi.fedoraproject.org/updates/FEDORA-2020-ef530c53af

--- Comment #3 from Fedora Update System  ---
FEDORA-2020-64dc185f10 has been submitted as an update to Fedora 32.
https://bodhi.fedoraproject.org/updates/FEDORA-2020-64dc185f10


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1880857] perl-Module-CoreList-5.20200920 is available

[bugzilla]

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



--- Comment #1 from Fedora Update System  ---
FEDORA-2020-ef530c53af has been submitted as an update to Fedora 33.
https://bodhi.fedoraproject.org/updates/FEDORA-2020-ef530c53af

--- Comment #3 from Fedora Update System  ---
FEDORA-2020-64dc185f10 has been submitted as an update to Fedora 32.
https://bodhi.fedoraproject.org/updates/FEDORA-2020-64dc185f10

--- Comment #3 from Fedora Update System  ---
FEDORA-2020-18b12f28fa has been submitted as an update to Fedora 31.
https://bodhi.fedoraproject.org/updates/FEDORA-2020-18b12f28fa


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1880852] perl-HTTP-CookieJar-0.010 is available

[bugzilla]

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

Jitka Plesnikova  changed:

   What|Removed |Added

 Status|NEW |CLOSED
 CC||jples...@redhat.com
   Fixed In Version||perl-HTTP-CookieJar-0.010-1
   ||.fc34
 Resolution|--- |RAWHIDE
   Doc Type|--- |If docs needed, set a value
Last Closed||2020-09-21 08:48:47



--- Comment #3 from Jitka Plesnikova  ---
Built by yaneti


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1874449] Upgrade perl-Type-Tiny to 1.010006

[bugzilla]

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

Jitka Plesnikova  changed:

   What|Removed |Added

 Status|NEW |CLOSED
   Fixed In Version||perl-Type-Tiny-1.010006-1.f
   ||c34
   ||perl-Type-Tiny-1.010006-1.f
   ||c33
 Resolution|--- |RAWHIDE
Last Closed||2020-09-21 08:46:09



--- Comment #2 from Jitka Plesnikova  ---
Built by corsepiu


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1880859] perl-CPAN-Perl-Releases-5.20200920 is available

[bugzilla]

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



--- Comment #1 from Fedora Update System  ---
FEDORA-2020-8df3ccbaa1 has been submitted as an update to Fedora 33.
https://bodhi.fedoraproject.org/updates/FEDORA-2020-8df3ccbaa1

--- Comment #2 from Fedora Update System  ---
FEDORA-2020-a5b6a25059 has been submitted as an update to Fedora 32.
https://bodhi.fedoraproject.org/updates/FEDORA-2020-a5b6a25059


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1880859] perl-CPAN-Perl-Releases-5.20200920 is available

[bugzilla]

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



--- Comment #1 from Fedora Update System  ---
FEDORA-2020-8df3ccbaa1 has been submitted as an update to Fedora 33.
https://bodhi.fedoraproject.org/updates/FEDORA-2020-8df3ccbaa1


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1880857] perl-Module-CoreList-5.20200920 is available

[bugzilla]

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

Jitka Plesnikova  changed:

   What|Removed |Added

 Status|ASSIGNED|MODIFIED
   Fixed In Version||perl-Module-CoreList-5.2020
   ||0920-1.fc34




-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1880857] perl-Module-CoreList-5.20200920 is available

[bugzilla]

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

Jitka Plesnikova  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 CC|jose.p.oliveira.oss@gmail.c |
   |om, spo...@gmail.com,   |
   |st...@silug.org |
   Doc Type|--- |If docs needed, set a value




-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

Re: Fwd: Copr package build fails on python-nocaselist package

[Pavel Raiskup]

On Monday, September 21, 2020 9:07:32 AM CEST Andreas R Maier wrote:
> Hello Robert,
> I suspect the reason I get the python-%{srcname}-%{version} in the .tar.gz
> file is that I was setting up COPR to use "rpkg". When using "copr-cli build"
> as shown in your mail, it works on COPR. So I think we can ignore that issue.

Please consider reporting this against rpkg-util:
https://pagure.io/rpkg-util

Pavel

> At this point, I can successfully build locally (with "rpmbuild -bb"), on 
> Koji (with "koji build"), and on COPR (with "copr-cli build").
> 
> I cannot yet build locally with "fedpkg mockbuild" or on Koji with "fedpkg 
> scratch-build", and I suspect this is because there is no repo for the 
> package yet and/or because I have not set up the mock environment on my local 
> Fedora.
> 
> What I still don't understand is the package name: "rpmbuild -bs" creates an 
> SRPM with package name "python3-nocaselist" while "fedpkg srpm" creates an 
> SRPM with package name "python-nocaselist". What will be the package name in 
> Fedora at the end of the day?
> 
> Andy
> 
> > Begin forwarded message:
> > 
> > From: Robert-André Mauchin 
> > Subject: Re: Copr package build fails on python-nocaselist package
> > Date: 18. September 2020 at 13:46:53 CEST
> > To: Development discussions related to Fedora 
> > 
> > Reply-To: Development discussions related to Fedora 
> > 
> > 
> > The archives in your SRPM are different:
> > - on COPR the root directory of your archive is 
> > python-%{srcname}-%{version} 
> > - on Koji the root directory of your archive is %{srcname}-%{version}
> > 
> > Check that you have deleted python-%{srcname}-%{version}.tar.gz before 
> > regenerating the SRPM.
> > 
> > Also I never use rpmbuild anymore, I do everything in the same directory 
> > with 
> > fedpkg:
> > 
> > ## Building the Fedora package
> > 
> > ### Build the source RPM locally:
> > 
> >rm *.tar.gz *src.rpm
> >spectool -g *.spec && fedpkg --release f34 srpm
> > 
> > ### Build the binary RPM locally in a mock chroot:
> > 
> >fedpkg --release f34  mockbuild --mock-config fedora-rawhide-x86_64 -N
> > 
> > Build logs and RPMs (if any) are in the results subdirectory
> > 
> > ### Build the binary RPM with the Koji build system:
> > 
> >fedpkg  --release f34 scratch-build --srpm --fail-fast
> > 
> > ### COPR:
> > 
> >copr-cli build python-nocaselist *.src.rpm
> > 
> > 
> > 
> > No idea where python-%{srcname}-%{version} in the .tar.gz is coming from, 
> > neither pypi or github have that archive. Maybe it's an artifact of 
> > building 
> > the SRPM with rpkg?
> > 
> > ___
> > devel mailing list -- devel@lists.fedoraproject.org
> > To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> > Fedora Code of Conduct: 
> > https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> > List Archives: 
> > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> 
> 



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

[Bug 1880859] perl-CPAN-Perl-Releases-5.20200920 is available

[bugzilla]

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

Jitka Plesnikova  changed:

   What|Removed |Added

 Status|ASSIGNED|MODIFIED
   Fixed In Version||perl-CPAN-Perl-Releases-5.2
   ||0200920-1.fc34




-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1880859] perl-CPAN-Perl-Releases-5.20200920 is available

[bugzilla]

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

Jitka Plesnikova  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 CC|iarn...@gmail.com   |
   Doc Type|--- |If docs needed, set a value




-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

Fwd: Copr package build fails on python-nocaselist package

[Andreas R Maier]

Hello Robert,
I suspect the reason I get the python-%{srcname}-%{version} in the .tar.gz file 
is that I was setting up COPR to use "rpkg". When using "copr-cli build" as 
shown in your mail, it works on COPR. So I think we can ignore that issue.

At this point, I can successfully build locally (with "rpmbuild -bb"), on Koji 
(with "koji build"), and on COPR (with "copr-cli build").

I cannot yet build locally with "fedpkg mockbuild" or on Koji with "fedpkg 
scratch-build", and I suspect this is because there is no repo for the package 
yet and/or because I have not set up the mock environment on my local Fedora.

What I still don't understand is the package name: "rpmbuild -bs" creates an 
SRPM with package name "python3-nocaselist" while "fedpkg srpm" creates an SRPM 
with package name "python-nocaselist". What will be the package name in Fedora 
at the end of the day?

Andy

> Begin forwarded message:
> 
> From: Robert-André Mauchin 
> Subject: Re: Copr package build fails on python-nocaselist package
> Date: 18. September 2020 at 13:46:53 CEST
> To: Development discussions related to Fedora 
> Reply-To: Development discussions related to Fedora 
> 
> 
> The archives in your SRPM are different:
> - on COPR the root directory of your archive is python-%{srcname}-%{version} 
> - on Koji the root directory of your archive is %{srcname}-%{version}
> 
> Check that you have deleted python-%{srcname}-%{version}.tar.gz before 
> regenerating the SRPM.
> 
> Also I never use rpmbuild anymore, I do everything in the same directory with 
> fedpkg:
> 
> ## Building the Fedora package
> 
> ### Build the source RPM locally:
> 
>rm *.tar.gz *src.rpm
>spectool -g *.spec && fedpkg --release f34 srpm
> 
> ### Build the binary RPM locally in a mock chroot:
> 
>fedpkg --release f34  mockbuild --mock-config fedora-rawhide-x86_64 -N
> 
> Build logs and RPMs (if any) are in the results subdirectory
> 
> ### Build the binary RPM with the Koji build system:
> 
>fedpkg  --release f34 scratch-build --srpm --fail-fast
> 
> ### COPR:
> 
>copr-cli build python-nocaselist *.src.rpm
> 
> 
> 
> No idea where python-%{srcname}-%{version} in the .tar.gz is coming from, 
> neither pypi or github have that archive. Maybe it's an artifact of building 
> the SRPM with rpkg?
> 
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

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

Re: Discussion: unixODBC - move unversioned *.so files back to unixODBC-devel package

[Ondrej Dubaj]

any other suggestions here ? I will be glad, if maintainers of dependent
packages will share their opinions. If we fix this issue and it breaks
dependent packages, simple workaround via symlink is available until the
problems will be solved, so I see no  reason for ignoring this problem.

On Fri, Sep 11, 2020 at 1:40 PM Vít Ondruch  wrote:

>
> Dne 11. 09. 20 v 9:48 Florian Weimer napsal(a):
> > * Tom Hughes via devel:
> >
> >> On 11/09/2020 07:13, Ondrej Dubaj wrote:
> >>
> >>> There seemed to be no big reason for moving the libraries to the
> >>> main package in the past, so I consider f34 as a good candidate for
> >>> such a change. It would be great, if  you share your opinions and
> >>> concerns for this topic.
> >> Tom Lane has explained the reason on the ticket, it's because the
> >> library is often dlopened by a client application instead of being
> >> linked to.
>
>
> "often" is relative. I see this mentioned for following packages:
>
>
> java-1.5.0-ibm-jdbc
>
> java-1.6.0-sun-jdbc
>
> java-1.5.0-bea-jdbc
>
>
> Which probably shares common history and at least one of them admitted
> the mistake [1] and started to use the versioned .so file.
>
> So are there any other cases?
>
>
> > Yes, that is sufficient reason not to do the move.  Third-party
> > applications will break.
>
>
> And they should be fixed. I understand there is never the right time to
> fix this, but if not now, then when?
>
>
> > Some people also really dislike installing
> > *-devel packages in production, so there might not be an easy fix for
> > them.
> >
> > The library probably should not have a versioned soname in the first
> > place, with backwards compatibility achieved by different means.  But
> > that does not matter now.
> >
> > Thanks,
> > Florian
>
>
> Vít
>
>
> [1] https://bugzilla.redhat.com/show_bug.cgi?id=215777#c24
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org