Re: Donate 1 minute of your time to test upgrades from F40 to F41

[Marcin Juszkiewicz]

On 3.09.2024 10:08, Leigh Scott wrote:


You have some other issue as all those rpmfusion dep issues are bogus.


Thanks for pointing it out. Sorted out rpmfusion issues.

Two problems left:

 Problem 1: package alizams-1.9.10-2.fc41.x86_64 from fedora requires 
libITKCommon-4.13.so.1()(64bit), but none of the providers can be installed
  - package alizams-1.9.10-2.fc41.x86_64 from fedora requires 
libITKStatistics-4.13.so.1()(64bit), but none of the providers can be installed
  - package alizams-1.9.10-2.fc41.x86_64 from fedora requires 
libITKTransform-4.13.so.1()(64bit), but none of the providers can be installed
  - package InsightToolkit-4.13.3-15.fc39.x86_64 from @System requires 
libtiff.so.5()(64bit), but none of the providers can be installed
  - package InsightToolkit-4.13.3-15.fc39.x86_64 from @System requires 
libtiff.so.5(LIBTIFF_4.0)(64bit), but none of the providers can be installed
  - package InsightToolkit-4.13.3-15.fc39.x86_64 from fedora requires 
libtiff.so.5()(64bit), but none of the providers can be installed
  - package InsightToolkit-4.13.3-15.fc39.x86_64 from fedora requires 
libtiff.so.5(LIBTIFF_4.0)(64bit), but none of the providers can be installed
  - problem with installed package alizams-1.9.9-2.fc40.x86_64
  - libtiff-4.6.0-2.fc40.x86_64 from @System  does not belong to a distupgrade 
repository
  - alizams-1.9.9-2.fc40.x86_64 from @System  does not belong to a distupgrade 
repository

 Problem 2: problem with installed package InsightToolkit-4.13.3-15.fc39.x86_64
  - package InsightToolkit-4.13.3-15.fc39.x86_64 from @System requires 
libtiff.so.5()(64bit), but none of the providers can be installed
  - package InsightToolkit-4.13.3-15.fc39.x86_64 from @System requires 
libtiff.so.5(LIBTIFF_4.0)(64bit), but none of the providers can be installed
  - package InsightToolkit-4.13.3-15.fc39.x86_64 from fedora requires 
libtiff.so.5()(64bit), but none of the providers can be installed
  - package InsightToolkit-4.13.3-15.fc39.x86_64 from fedora requires 
libtiff.so.5(LIBTIFF_4.0)(64bit), but none of the providers can be installed
  - cannot install both libtiff-4.6.0-6.fc41.x86_64 from fedora and 
libtiff-4.6.0-2.fc40.x86_64 from @System
  - package libtiff-devel-4.6.0-6.fc41.x86_64 from fedora requires 
libtiff(x86-64) = 4.6.0-6.fc41, but none of the providers can be installed
  - problem with installed package libtiff-devel-4.6.0-2.fc40.x86_64
  - libtiff-devel-4.6.0-2.fc40.x86_64 from @System  does not belong to a 
distupgrade repository

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

Re: Donate 1 minute of your time to test upgrades from F40 to F41

[Marcin Juszkiewicz]

On 2.09.2024 12:20, Miroslav Suchý wrote:
Do you want to make Fedora 41 better? Please spend 1 minute of your time 
and try to run:


dnf --releasever=41 --enablerepo=updates-testing --assumeno distro-sync


I have several packages from RPMFusion so some problems (1, 3, 4, 7,
9, 10, 11) are related to it:

 Problem 1: package ffmpeg-libs-6.1.2-2.fc40.x86_64 from @System requires 
libjxl.so.0.8()(64bit), but none of the providers can be installed
  - package ffmpeg-libs-6.1.2-2.fc40.x86_64 from @System requires 
libjxl.so.0.8(JXL_0)(64bit), but none of the providers can be installed
  - package ffmpeg-libs-6.1.2-2.fc40.x86_64 from @System requires 
libjxl_threads.so.0.8()(64bit), but none of the providers can be installed
  - package ffmpeg-libs-6.1.2-2.fc40.x86_64 from @System requires 
libjxl_threads.so.0.8(JXL_0)(64bit), but none of the providers can be installed
  - libjxl-1:0.8.3-1.fc40.x86_64 from @System  does not belong to a distupgrade 
repository
  - problem with installed package ffmpeg-libs-6.1.2-2.fc40.x86_64

 Problem 3: package mesa-vdpau-drivers-freeworld-24.1.6-1.fc40.x86_64 from 
@System requires mesa-filesystem(x86-64) = 24.1.6, but none of the providers 
can be installed
  - mesa-filesystem-24.1.6-1.fc40.x86_64 from @System  does not belong to a 
distupgrade repository
  - problem with installed package 
mesa-vdpau-drivers-freeworld-24.1.6-1.fc40.x86_64

 Problem 4: package python3-rpmfusion-cert-0.7.2-8.fc40.noarch from @System 
requires python(abi) = 3.12, but none of the providers can be installed
  - python3-3.12.5-1.fc40.x86_64 from @System  does not belong to a distupgrade 
repository
  - problem with installed package python3-rpmfusion-cert-0.7.2-8.fc40.noarch

 Problem 7: package rpmfusion-free-release-40-0.1.noarch from @System requires 
system-release(40), but none of the providers can be installed
  - fedora-release-40-39.noarch from @System  does not belong to a distupgrade 
repository
  - problem with installed package rpmfusion-free-release-40-0.1.noarch

 Problem 9: package ffmpeg-libs-6.1.2-2.fc40.x86_64 from @System requires 
libplacebo.so.338()(64bit), but none of the providers can be installed
  - package ffmpeg-6.1.2-2.fc40.x86_64 from @System requires 
ffmpeg-libs(x86-64) = 6.1.2-2.fc40, but none of the providers can be installed
  - libplacebo-6.338.2-1.fc40.x86_64 from @System  does not belong to a 
distupgrade repository
  - problem with installed package ffmpeg-6.1.2-2.fc40.x86_64

 Problem 10: package ffmpeg-libs-6.1.2-2.fc40.x86_64 from @System requires 
libvmaf.so.1()(64bit), but none of the providers can be installed
  - package libavdevice-6.1.2-2.fc40.x86_64 from @System requires 
ffmpeg-libs(x86-64) = 6.1.2-2.fc40, but none of the providers can be installed
  - libvmaf-2.3.0-7.fc40.x86_64 from @System  does not belong to a distupgrade 
repository
  - problem with installed package libavdevice-6.1.2-2.fc40.x86_64

 Problem 11: package python3-rpmfusion-cert-0.7.2-8.fc40.noarch from @System 
requires python(abi) = 3.12, but none of the providers can be installed
  - package python3-3.12.5-1.fc40.x86_64 from @System requires 
python3-libs(x86-64) = 3.12.5-1.fc40, but none of the providers can be installed
  - package rpmfusion-packager-0.7.2-8.fc40.noarch from @System requires 
python3-rpmfusion-cert, but none of the providers can be installed
  - python3-libs-3.12.5-1.fc40.x86_64 from @System  does not belong to a 
distupgrade repository
  - problem with installed package rpmfusion-packager-0.7.2-8.fc40.noarch


Two are libtiff related:

 Problem 12: package alizams-1.9.10-2.fc41.x86_64 from fedora requires 
libITKCommon-4.13.so.1()(64bit), but none of the providers can be installed
  - package alizams-1.9.10-2.fc41.x86_64 from fedora requires 
libITKStatistics-4.13.so.1()(64bit), but none of the providers can be installed
  - package alizams-1.9.10-2.fc41.x86_64 from fedora requires 
libITKTransform-4.13.so.1()(64bit), but none of the providers can be installed
  - package InsightToolkit-4.13.3-15.fc39.x86_64 from @System requires 
libtiff.so.5()(64bit), but none of the providers can be installed
  - package InsightToolkit-4.13.3-15.fc39.x86_64 from @System requires 
libtiff.so.5(LIBTIFF_4.0)(64bit), but none of the providers can be installed
  - package InsightToolkit-4.13.3-15.fc39.x86_64 from fedora requires 
libtiff.so.5()(64bit), but none of the providers can be installed
  - package InsightToolkit-4.13.3-15.fc39.x86_64 from fedora requires 
libtiff.so.5(LIBTIFF_4.0)(64bit), but none of the providers can be installed
  - problem with installed package alizams-1.9.9-2.fc40.x86_64
  - libtiff-4.6.0-2.fc40.x86_64 from @System  does not belong to a distupgrade 
repository
  - alizams-1.9.9-2.fc40.x86_64 from @System  does not belong to a distupgrade 
repository

 Problem 14: problem with installed package InsightToolkit-4.13.3-15.fc39.x86_64
  - package InsightToolkit-4.13.3-15.fc39.x86_64 from @System requires 
libtiff.so.5()(64bit), but none of the prov

Re: List of long term FTBFS packages to be retired in July

[Marcin Juszkiewicz]

W dniu 27.06.2024 o 02:02, Peter Hutterer pisze:

On Wed, Jun 26, 2024 at 10:40:33AM +0200, Marcin Juszkiewicz wrote:

W dniu 25.06.2024 o 23:29, Miro Hrončok pisze:

Depending on: libratbag (1)
  piper (maintained by: vtrefny)
      piper-0.7-8.fc41.noarch requires libratbag-ratbagd
      piper-0.7-8.fc41.src requires libratbag-ratbagd


Added fix to https://bugzilla.redhat.com/show_bug.cgi?id=2225974 report.


thanks, I've applied this one now. ftr, libratbag is effectively
unmaintained and really should be orphaned.


It is a useful project (finally configured my mouse without running MS 
Windows) but yeah, development style of it makes it hard to comment.


0.17 was released 1.5 year ago, work on 0.18 feels stalled. Lot of 
devices were added in meantime but no release == not used by most of 
users (if they know about project at all).

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

Re: List of long term FTBFS packages to be retired in July

[Marcin Juszkiewicz]

W dniu 25.06.2024 o 23:29, Miro Hrončok pisze:

Depending on: libratbag (1)
 piper (maintained by: vtrefny)
     piper-0.7-8.fc41.noarch requires libratbag-ratbagd
     piper-0.7-8.fc41.src requires libratbag-ratbagd


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

Re: Three steps we could take to make supply chain attacks a bit harder

[Marcin Juszkiewicz]

W dniu 30.03.2024 o 10:37, Richard W.M. Jones pisze:

(1) We should routinely delete autoconf-generated cruft from upstream
projects and regenerate it in %prep.  It is easier to study the real
source rather than dig through the convoluted, generated shell script
in an upstream './configure' looking for back doors.

For most projects, just running "autoreconf -fiv" is enough.

Yes, there are some projects that depend on a specific or old version
of autoconf.  We should fix those.  But that doesn't need to delay us
from using autoreconf on many projects today.

In the xz case this wouldn't have been enough, it turns out we would
also have to delete m4/build-to-host.m4, which then autoreconf
regenerates.  I don't fully understand why that is.


There were also projects where configure script was generated long time 
ago and then edited by hand. Usually because no one in project knew m4.

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

Re: F41 Change Proposal: PHP no 32 bit / PHP 64-bit only (self-contained)

[Marcin Juszkiewicz]

W dniu 8.03.2024 o 21:50, Aoife Moloney pisze:

== Detailed Description ==
PHP is not a library, so is not multilib.
32-bit consumes builder CPU/time, but nothing is shipped in the repositories.

A lot of projects don't have 32-bit CI, so this may raise FTBFS (10 in
F40 Mass Rebuild)

Add for all extension packages:

'''ExcludeArch: %{ix86}'''


Recently I was wondering when Fedora will do opposite. Disable 32-bit 
x86 builds for all packages and leave it explicitly enabled for those 
packages which are used for multilib purposed.


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

Re: dmesg restricted to root in Rawhide

[Marcin Juszkiewicz]

W dniu 27.02.2024 o 22:27, Justin Forbes pisze:

In practice, this isn't that much of a lockdown for most fedora users.
We give the default user on a system wheel access which means both
'sudo dmesg' and 'journalctl -k' work as is.

You wish...

$ id
uid=1003(marcin) gid=1006(marcin) 
groups=1006(marcin),10(wheel),11(cdrom),18(dialout),39(video),63(audio),100(users),135(mock),948(render),960(libvirt),986(wireshark),1003(docker) 
context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023

$ dmesg
dmesg: read kernel buffer failed: Operation not permitted
$ uname -a
Linux puchatek.local 6.8.0-0.rc5.41.fc40.x86_64 #1 SMP PREEMPT_DYNAMIC 
Mon Feb 19 14:19:27 UTC 2024 x86_64 GNU/Linux

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

Re: dnf-4.19.0 without filelists in Rawhide soon

[Marcin Juszkiewicz]

W dniu 9.02.2024 o 14:02, Jan Kolarik pisze:
Just a heads up that a new DNF version (4.19.0) is on its way to Rawhide 
and is expected to land within the next several hours. This update 
brings a system-wide change 
 related 
to not downloading filelists metadata by default.


So no more "dnf install /usr/bin/BINARYNAME" in default setup?
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: just to let you know FESCo agreed to a preliminary injunction while we consider this issue

[Marcin Juszkiewicz]

W dniu 9.02.2024 o 20:25, Roy Bekken pisze:

I just booted Fedora-KDE-Live-x86_64-Rawhide-20240207.n.0.iso First
impression is great but I’ll start moving(fast) the welcome center 
window around and the desktop randomly freezes from 30sec to 90ses.


This is on a 1080 with nouveau, im not sure if its better with the
proprietary drivers.


NVidia 10xx is the worst option for nouveau.

It is too new to have reclocking support (NVidia never released 
blobs/code for it for this generation).


And it is too old to use new GSP based approach where you run tens of 
megabytes of blob and use nouveau on top of it.


For 1080 the only option is proprietary driver. With all problems it 
generates.



I had 1050 Ti. Sold it, moved to Radeon 6700 XT. Wayland works, X11 
works, Cyberpunk 2077 works (both under Linux and Windows).

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

Re: Erlang 26 broke rabbitmq

[Marcin Juszkiewicz]

W dniu 13.12.2023 o 19:51, Adam Williamson pisze:

Lately I'm working on the Bodhi development environment, and I reached
a point where I noticed rabbitmq was not working inside my current,
Fedora 39-based version of it.

This appears to be because rabbitmq 3.11 simply does not work with
Erlang 26. Fedora 39 has erlang 26 and rabbitmq 3.11. 


Whoever works on Erlang should work on RabbitMQ too. That's what I 
learnt (hard way) from working on releasing OpenStack.


Those two components are so linked with each other that you cannot 
"just" upgrade one or another - they have to be in sync. Upstream has a 
table listing which versions of RabbitMQ work with which versions of Erlang:


1. https://rabbitmq.com/which-erlang.html

Erlang 26 means RabbitMQ 3.12.* because 3.11.* wants 25 one.


Can we please avoid this circumstance in future by again using the
Change process and considering dependencies for any future major Erlang
bump? Thanks. It looks like we will need to update rabbitmq to 3.12 for
it to stand any chance of working in 39 or Rawhide. I will see if
that's a straightforward change next, and try to send a PR if so.


As long as you upgrade RabbitMQ from 3.x to 3.(x+1) and keep Erlang 
versions in sync it should be fine.



NOTE: I never wrote a line in Erlang. Nor used it with something other 
than RabbitMQ.

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

Re: F40 Change Proposal: KDE Plasma 6 (System Wide)

[Marcin Juszkiewicz]

W dniu 13.09.2023 o 17:53, Aoife Moloney pisze:


== Summary ==
KDE Plasma 6 is successor to KDE Plasma 5 created by the KDE
Community. It is based on Qt 6 and KDE Frameworks 6 and brings many
changes and improvements over previous versions. For Fedora Linux, the
transition to KDE Plasma 6 will also include dropping support for the
X11 session entirely, leaving only Plasma Wayland as the sole offered
desktop mode.


Which leaves us with "Numpad shortcuts don't work in wayland sessions" 
bug in KDE/Wayland:


https://bugs.kde.org/show_bug.cgi?id=453423

Someone in KDE decided to treat KEY_KP1 ("1" on numpad part of pc105 
keyboard) in same way as KEY_1 ("1" on alphanumeric part of pc105 
keyboard). Which breaks several setups where people use shortcuts with 
numpad keys (for me it is Meta+KP[1-9] to organize windows).



This bug is one of reasons I am still on KDE/X11 rather than KDE/Wayland.

Other reasons are:

1. Zoom meeting app which is unable to share Wayland windows
2. RSIBreak app is unable to track activity
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Donate 1 minute of your time to test upgrades from F38 to F39

[Marcin Juszkiewicz]

W dniu 29.08.2023 o 17:26, Adam Williamson pisze:

On Tue, 2023-08-29 at 10:33 +0200, Marcin Juszkiewicz wrote:


   Problem 2: package ghc-data-array-byte-0.1.0.1-1.fc38.x86_64 from @System 
requires libHSarray-0.5.4.0-ghc9.2.6.so()(64bit), but none of the providers can 
be installed
- ghc-array-0.5.4.0-133.fc38.x86_64 from @System  does not belong to a 
distupgrade repository
- problem with installed package ghc-data-array-byte-0.1.0.1-1.fc38.x86_64

Looks like package got dropped in meantime.


Such packages ought to be obsoleted by something - if nothing else, by
fedora-obsolete-packages . You can file a bug or PR asking for it to be
added there.


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

Re: Donate 1 minute of your time to test upgrades from F38 to F39

[Marcin Juszkiewicz]

W dniu 23.08.2023 o 20:22, Miroslav Suchý pisze:
Do you want to make Fedora 39 better? Please spend 1 minute of your time 
and try to run:


# Run this only if you use default Fedora modules
# next time you run any DNF command default modules will be enabled again
sudo dnf module reset '*'

dnf --releasever=39 --setopt=module_platform_id=platform:f39 \
--enablerepo=updates-testing \
$(rpm -q fedora-repos-modular >/dev/null && echo 
--enablerepo=updates-testing-modular) \

--assumeno distro-sync



 Problem 1: problem with installed package 
mesa-vdpau-drivers-freeworld-23.0.2-1.fc38.x86_64
  - mesa-vdpau-drivers-freeworld-23.0.2-1.fc38.x86_64 from @System  does not 
belong to a distupgrade repository
  - nothing provides mesa-filesystem(x86-64) = 23.1.5 needed by 
mesa-vdpau-drivers-freeworld-23.1.5-1.fc39.x86_64 from rpmfusion-free

That's rpmfusion so will be sorted out.


 Problem 2: package ghc-data-array-byte-0.1.0.1-1.fc38.x86_64 from @System 
requires libHSarray-0.5.4.0-ghc9.2.6.so()(64bit), but none of the providers can 
be installed
  - ghc-array-0.5.4.0-133.fc38.x86_64 from @System  does not belong to a 
distupgrade repository
  - problem with installed package ghc-data-array-byte-0.1.0.1-1.fc38.x86_64

Looks like package got dropped in meantime.


 Problem 3: package python3-PyDrive-1.3.1-21.fc37.noarch from @System requires 
python(abi) = 3.11, but none of the providers can be installed
  - python3-3.11.4-1.fc38.x86_64 from @System  does not belong to a distupgrade 
repository
  - problem with installed package python3-PyDrive-1.3.1-21.fc37.noarch

Already discussed, obsolete package.

 Problem 4: problem with installed package 
python3-async-generator-1.10-16.fc38.noarch
  - package python3-async-generator-1.10-16.fc38.noarch from @System requires 
python(abi) = 3.11, but none of the providers can be installed
  - package python3-async-generator-1.10-16.fc38.noarch from fedora requires 
python(abi) = 3.11, but none of the providers can be installed
  - package python3-async-generator-1.10-16.fc38.noarch from 
updates-testing-modular requires python(abi) = 3.11, but none of the providers 
can be installed
  - package python3-3.11.4-1.fc38.x86_64 from @System requires 
python3-libs(x86-64) = 3.11.4-1.fc38, but none of the providers can be installed
  - python3-libs-3.11.4-1.fc38.x86_64 from @System  does not belong to a 
distupgrade repository

Also already discussed.


DNF5 managed to solve problems on it's own:

Transaction Summary:
 Installing:   47 packages
 Upgrading:  3803 packages
 Replacing:  3841 packages
 Removing:  7 packages
 Downgrading:  28 packages

Total size of inbound packages is 4 GiB. Need to download 4 GiB.
After this operation 669 MiB will be used (install 16 GiB, remove 16 GiB).
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: UW-IMAP

[Marcin Juszkiewicz]

W dniu 29.06.2023 o 16:27, David Both pisze:

I also spent about 4 days trying to get Dovecot to work with SendMail in
a test VM setup. I'm either missing one or more important bits or its
just too complex for me. None of the docs I have found anywhere has a
complete start-to-finish picture.


Jan Wildeboer wrote nice set of steps for Postfix + Dovecot combo. With 
SPF, DKIM etc.


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

Re: UW-IMAP

[Marcin Juszkiewicz]

W dniu 29.06.2023 o 14:57, David Both pisze:

I have noticed that uw-imap is no longer in the Fedora repo and that the
last was F33. I like it far better than the other options because it is
the IMAP server that best "does one things and does it well." It also
requires the least amount of configuration and it just works so it also
meets the KISS test.


UW IMAP development ended in 2008. Development of Panda IMAP (successor) 
ended in 2012 when Mark Crispin died.


https://github.com/jonabbey/panda-imap holds complete public history.

I would rather go Dovecot rather than revive 11 years old project. Did 
setup of it once, about 10 years, and it serves my private mail since then.

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

Re: Ridiculous new Red Hat Bugzilla password security requirements

[Marcin Juszkiewicz]

W dniu 14.10.2022 o 03:39, Kevin Kofler via devel pisze:


today, Red Hat Bugzilla forced me to change my password because
apparently a password of 9 random alphanumeric+symbol characters (1
symbol, 8 mixed-case alphanumeric) is suddenly no longer considered
secure enough. This is absolutely ridiculous for a bug tracker.


This bug tracker is also used to track several other products. Has 
several bug raports marked as private for security or confidential or 
other reasons. Fedora is just one of products tracked there.



It is not like that password is for a bank account or for a build
system (I believe FAS and thus Koji actually has less stringent
password security requirements than that!), so how secure does the
password really have to be?


9 characters password in 2022 is considered 'easy breakable' thanks to 
power of GPUs.


Maybe start using some password manager to generate and store long 
enough passwords? Or invent easy to remember ones like "I am Kevin 
Kofler and this is my password#$78"?

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

Re: Donate 1 minute of your time to test upgrades from F36 to F37

[Marcin Juszkiewicz]

W dniu 12.09.2022 o 14:59, Miroslav Suchý pisze:
Do you want to make Fedora 37 better? Please spend 1 minute of your time 
and try to run:


# Run this only if you use default Fedora modules
# next time you run any DNF command default modules will be enabled again
sudo dnf module reset '*'

dnf --releasever=37 --setopt=module_platform_id=platform:f37 \
--enablerepo=updates-testing \
$(rpm -q fedora-repos-modular >/dev/null && echo 
--enablerepo=updates-testing-modular) \

--assumeno distro-sync


No issues this time:

Transaction Summary
=
Install  48 Packages
Upgrade4450 Packages
Remove7 Packages
Downgrade   131 Packages

Total download size: 6.3 G
Operation aborted.

Removal is the usual one - kernel, nvidia and some Python.

Downgrade is mostly KDE. Plus grubby, hdparm and some cmake.

I am waiting for "downgrade" number to go further down (it was at 233 
last week) and upgrade this or next week.


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

Re: Thunderbird 102 pushed to F36 stable

[Marcin Juszkiewicz]

W dniu 3.09.2022 o 10:47, Demi Marie Obenour pisze:

On 9/3/22 04:42, Marcin Juszkiewicz wrote:

W dniu 3.09.2022 o 02:56, l...@fedoraproject.org pisze:



Which addons are incompatible? Additionally, use "Addon Compatibility
Check" for the purpose. The best practice is to contact these addons
developers fixing their issues.



After using Thunderbird for over 10 years I have a feeling that addons
developers more often abandon their addons when Thunderbird breaks
compatibility rather than continue working on them.



Can you name specific addons?


External Editor for example - worked up to v90 (or whichever was the 
previous "we break extensions" point). Current solution to get it 
working is so bizarre that I prefer to forget about it.


I stopped adding new extensions some time ago to not get used to extra 
functionality which may/will vanish with version update.


Now I have 11 extensions working and removed all which stopped being 
compatible.

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

Re: Thunderbird 102 pushed to F36 stable

[Marcin Juszkiewicz]

W dniu 3.09.2022 o 02:56, l...@fedoraproject.org pisze:

Here we go again: thunderbird 102 update was submitted to F36.

This new version was known to bring incompatible changes to several
addons, yet it has been submitted to a stable Fedora release with
autopush enable and just a karma threshold of 2. It took less than 5
hours from the time the update was submitted to the time the update was
pushed to stable.


Which addons are incompatible? Additionally, use "Addon Compatibility 
Check" for the purpose. The best practice is to contact these addons 
developers fixing their issues.


After using Thunderbird for over 10 years I have a feeling that addons 
developers more often abandon their addons when Thunderbird breaks 
compatibility rather than continue working on them.


More and more functionality present in addons goes away when Tb devs 
remove apis used by addons.

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

Re: Fedora 37: Add kernel parameters that help prevent local exploits

[Marcin Juszkiewicz]

W dniu 19.05.2022 o 05:15, Hellosway Here via devel pisze:

Add `slab_nomerge init_on_alloc=1 init_on_free=1 page_alloc.shuffle=1
pti=on randomize_kstack_offset=on vsyscall=none ` as default kernel
command line arguments. 


Some of them are a matter of kernel configuration options. Which is 
better option than adding yet another set of variables to kernel command 
line.

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

Re: Request for Intel WiFi Backports - AX2xx

[Marcin Juszkiewicz]

W dniu 28.12.2021 o 00:30, Kevin Anderson pisze:


There was a iwlwifi issue that would cause firmware resets and cause
performance to significantly degrade to around ~500Kb/s till the
interface was brought down and then up again. Upstream identified the
issue and there are 2 patches that fix the issue by increasing the
scan timeout[1] and in cases where the firmware resets allows it to
recover quicker[2]. The patch to allow for quicker firmware recovery
is present in Linus' tree and present in the 5.16 rc releases while
the patch to prevent the firmware from crashing in the instance is in
net-next for 5.17.


Did anyone thought of merging those patches into 5.15-stable upstream?

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

Re: Donate 1 minute of your time to test upgrades from F34 to F35

[Marcin Juszkiewicz]

On 07.09.2021 20:47, Marcin Juszkiewicz wrote:
[root@puchatek hrw]# LANGUAGE=C LC_ALL=C LANG=C dnf --releasever=35 
--setopt=module_platform_id=platform:f35 --enablerepo=updates-testing 
--enablerepo=updates-testing-modular distro-sync

Last metadata expiration check: 0:28:08 ago on Tue Sep  7 20:16:12 2021.
Error:
  Problem: package qt5-qtbase-ibase-5.15.2-16.fc34.x86_64 requires 
qt5-qtbase(x86-64) = 5.15.2-16.fc34, but none of the providers can be 
installed
   - qt5-qtbase-5.15.2-16.fc34.x86_64 does not belong to a distupgrade 
repository

   - problem with installed package qt5-qtbase-ibase-5.15.2-16.fc34.x86_64
(try to add '--skip-broken' to skip uninstallable packages)


Removed "qt5-qtbase-ibase" package and distrosync command went fine:


From qt5-qtbase changelog it looks like this package was disabled due 
to Firebird FTBFS on s390x which was later fixed.


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

Re: Donate 1 minute of your time to test upgrades from F34 to F35

[Marcin Juszkiewicz]

On 07.09.2021 18:14, Miroslav Suchý wrote:
Do you want to make Fedora 35 better? Please spend 1 minute of your time 
and try to run:


# Run this only if you use default Fedora modules
# next time you run any DNF command default modules will be enabled again
sudo dnf module reset '*'

sudo dnf --releasever=35 --setopt=module_platform_id=platform:f35 \

--enablerepo=updates-testing --enablerepo=updates-testing-modular \

distro-sync


[root@puchatek hrw]# LANGUAGE=C LC_ALL=C LANG=C dnf --releasever=35 
--setopt=module_platform_id=platform:f35 --enablerepo=updates-testing 
--enablerepo=updates-testing-modular distro-sync

Last metadata expiration check: 0:28:08 ago on Tue Sep  7 20:16:12 2021.
Error:
 Problem: package qt5-qtbase-ibase-5.15.2-16.fc34.x86_64 requires 
qt5-qtbase(x86-64) = 5.15.2-16.fc34, but none of the providers can be 
installed
  - qt5-qtbase-5.15.2-16.fc34.x86_64 does not belong to a distupgrade 
repository

  - problem with installed package qt5-qtbase-ibase-5.15.2-16.fc34.x86_64
(try to add '--skip-broken' to skip uninstallable packages)


Removed "qt5-qtbase-ibase" package and distrosync command went fine:

Install 118 Packages
Upgrade4434 Packages
Remove3 Packages
Downgrade14 Packages

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

Re: F35 Change: Build Fedora Cloud Images with Hybrid BIOS+UEFI Boot Support (System-Wide Change)

[Marcin Juszkiewicz]

W dniu 21.06.2021 o 17:43, Chris Murphy pisze:

Please make first partition at least 4MB in size. Those Arm/AArch64
systems which store bootloaders on boot media will have a space for it
(as some already read from around that area).

I'm confused what image(s) you're referring


Sorry, my mistake. I used too many images recently and missed 'cloud' in 
name.

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

Re: F35 Change: Build Fedora Cloud Images with Hybrid BIOS+UEFI Boot Support (System-Wide Change)

[Marcin Juszkiewicz]

W dniu 03.06.2021 o 22:35, Ben Cotton pisze:

https://fedoraproject.org/wiki/Changes/FedoraCloudHybridBoot

== Summary ==

With recent changes in public cloud widely accepting the
use of UEFI boot, it would be consistent to add hybrid boot in support of
both unifying the legacy (BIOS) and UEFI boot to the Fedora Linux
cloud base images.




== Detailed Description ==
The Fedora Cloud Edition image will be updated to be configured with
multiple partitions and a GPT label instead of one single partition
and implicit MBR.

The partition order will be:

# A BIOS boot partition
# An EFI System partition
# A general data partition


Please make first partition at least 4MB in size. Those Arm/AArch64 
systems which store bootloaders on boot media will have a space for it 
(as some already read from around that area).

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

F32 -> F33 upgrade

[Marcin Juszkiewicz]

I assume that there will be a proper thread for testing such upgrade
some time after Beta point but I had some time today I checked will it
work.

On my system it looks like deja-dup/duply/duplicity have a problem with
dependencies:

[root@puchatek ~]# LANGUAGE=C dnf distrosync --releasever 33 
Last metadata expiration check: 0:18:13 ago on nie, 13 wrz 2020, 13:50:13.
Error: 

Problem 1: problem with installed package 
python3-google-api-client-1:1.6.7-11.fc32.noarch
  - python3-google-api-client-1:1.6.7-11.fc32.noarch does not belong to a 
distupgrade repository
  - nothing provides python3-google-api-core >= 1.18.0 needed by 
python3-google-api-client-1:1.10.0-2.fc33.noarch

Problem 2: package duplicity-0.8.15-2.fc33.x86_64 requires python3-PyDrive, but 
none of the providers can be installed
  - problem with installed package duplicity-0.8.15-2.fc32.x86_64
  - package python3-PyDrive-1.3.1-13.fc33.noarch requires 
python3.9dist(google-api-python-client) >= 1.2, but none of the providers can 
be installed
  - python3-PyDrive-1.3.1-12.fc32.noarch does not belong to a distupgrade 
repository
  - duplicity-0.8.15-2.fc32.x86_64 does not belong to a distupgrade repository
  - nothing provides python3-google-api-core >= 1.18.0 needed by 
python3-google-api-client-1:1.10.0-2.fc33.noarch

Problem 3: problem with installed package python3-PyDrive-1.3.1-12.fc32.noarch
  - package python3-PyDrive-1.3.1-12.fc32.noarch requires python(abi) = 3.8, 
but none of the providers can be installed
  - package python3-PyDrive-1.3.1-13.fc33.noarch requires 
python3.9dist(google-api-python-client) >= 1.2, but none of the providers can 
be installed
  - python3-3.8.5-5.fc32.x86_64 does not belong to a distupgrade repository
  - nothing provides python3-google-api-core >= 1.18.0 needed by 
python3-google-api-client-1:1.10.0-2.fc33.noarch

Problem 4: package duply-2.2.2-2.fc33.noarch requires duplicity, but none of 
the providers can be installed
  - package duplicity-0.8.15-2.fc33.x86_64 requires python3-PyDrive, but none 
of the providers can be installed
  - package duplicity-0.8.15-2.fc32.x86_64 requires python(abi) = 3.8, but none 
of the providers can be installed
  - package python3-PyDrive-1.3.1-12.fc32.noarch requires 
python3.8dist(oauth2client) >= 4, but none of the providers can be installed
  - package python3-3.8.5-5.fc32.x86_64 requires python3-libs(x86-64) = 
3.8.5-5.fc32, but none of the providers can be installed
  - problem with installed package duply-2.2.2-1.fc32.noarch
  - package python3-PyDrive-1.3.1-13.fc33.noarch requires 
python3.9dist(google-api-python-client) >= 1.2, but none of the providers can 
be installed
  - python3-oauth2client-4.1.3-10.fc32.noarch does not belong to a distupgrade 
repository
  - python3-libs-3.8.5-5.fc32.x86_64 does not belong to a distupgrade repository
  - duply-2.2.2-1.fc32.noarch does not belong to a distupgrade repository
  - nothing provides python3-google-api-core >= 1.18.0 needed by 
python3-google-api-client-1:1.10.0-2.fc33.noarch

Problem 5: package deja-dup-42.2-1.fc33.x86_64 requires duplicity >= 0.6.23, 
but none of the providers can be installed
  - package duplicity-0.8.15-2.fc32.x86_64 requires python3-PyDrive, but none 
of the providers can be installed
  - package duplicity-0.8.15-2.fc33.x86_64 requires python3-PyDrive, but none 
of the providers can be installed
  - package python3-PyDrive-1.3.1-12.fc32.noarch requires python3.8dist(pyyaml) 
>= 3, but none of the providers can be installed
  - problem with installed package deja-dup-42.2-1.fc32.x86_64
  - package python3-PyDrive-1.3.1-13.fc33.noarch requires 
python3.9dist(google-api-python-client) >= 1.2, but none of the providers can 
be installed
  - python3-pyyaml-5.3.1-1.fc32.x86_64 does not belong to a distupgrade 
repository
  - deja-dup-42.2-1.fc32.x86_64 does not belong to a distupgrade repository
  - nothing provides python3-google-api-core >= 1.18.0 needed by 
python3-google-api-client-1:1.10.0-2.fc33.noarch
(try to add '--skip-broken' to skip uninstallable packages)
[root@puchatek ~]# 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: The future of legacy BIOS support in Fedora.

[Marcin Juszkiewicz]

W dniu 01.07.2020 o 12:57, Richard W.M. Jones pisze:

> If you mean migration of existing guests, then you need to repartition
> them and reinstall the bootloader.  I doubt anyone has a practical
> idea of how to do that either manually or automatically.

Add second drive with 32-64MB size. Create ESP partition there. Install
grub-efi. Power off, switch to UEFI mode, power on, boot to grub-efi.

Much easier than with real hardware machines where you indeed need to
play with partitions. On my laptop I have space available in /boot/ 
partition so could shrink it and create ESP from there. But already have
ESP so no need.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: The future of legacy BIOS support in Fedora.

[Marcin Juszkiewicz]

W dniu 30.06.2020 o 16:40, Daniel P. Berrangé pisze:
> On Tue, Jun 30, 2020 at 04:32:44PM +0200, Marcin Juszkiewicz wrote:

>> Can we also default to Q35 and forget that i440fx existed?
>>
>> Do all the pain in one step.
 
> That's upto the various mgmt apps using libvirt to decide. Q35
> is *NOT* a drop-in replacement for i440fx. IOW if libvirt flipped
> the switch existing mgmt apps would certainly break. For example, you
> can't hotplug with Q35, unless the mgmt app pre-populated a bunch of
> pcie-root-port devices. If the mgmt app is using IDE (eg for CDROM)
> it'll break because Q35 requires SATA. There's various other areas
> of pain. So we must let the mgmt apps decide when they are ready
> to switch to use Q35 instead of i440fx.

I am aware of those issues. AArch64 default mode is like Q35.

Wrote few words about that in past:

https://marcin.juszkiewicz.com.pl/2018/02/01/everyone-loves-90s-pc-hardware/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: The future of legacy BIOS support in Fedora.

[Marcin Juszkiewicz]

W dniu 30.06.2020 o 16:27, Daniel P. Berrangé pisze:

> KVM virt on aarch64 and x86 can support EFI via AVMF / OVMF firmware
> built from the edk2 project from a technical POV.
> 
> The first challenge will be that many mgmt tools still default to
> using legacy BIOS when deploying guest OS. We've been trying to
> make it easier for mgmt apps to "do the right thing" by having
> libosinfo record metadata about whether each guest OS supports
> legacy BIOS, EFI or both. ie we want the mgmt apps to just pick
> EFI if they see the OS doesn't support legacy BIOS, instead of
> requiring users to manually tell them to use EFI.

> So I can't say I'm thrilled about a future that depends on EFI for
> virt, but I'm resigned to the fact this is the direction the world
> is taking. So we're not likely to have any choice and will have to
> work to mitigate any downsides it brings.

Can we also default to Q35 and forget that i440fx existed?

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

Re: The future of legacy BIOS support in Fedora.

[Marcin Juszkiewicz]

W dniu 30.06.2020 o 16:20, Tom Hughes via devel pisze:
> On 30/06/2020 15:00, Florian Weimer wrote:
>> * Jóhann B. Guðmundsson:
>> 
>>> Given Hans proposal [1] introduced systemd/grub2/Gnome upstream 
>>> changes it beg the question if now would not be the time to stop 
>>> supporting booting in legacy bios mode and move to uefi only
>>> supported boot which has been available on any common intel based
>>> x86 platform since atleast 2005.
>> 
>> Even for virtualization?  Not sure if that can be done.
> 
> Good point. Certainly libvirt still defaults to legacy BIOS and I
> don't think UEFI is even possible without manually editing the XML
> definition for the machine.

New installs for x86-64 VM can be BIOS of UEFI for quite some years.
For both i440fx and q35 variants. 

Migration from BIOS to UEFI would require edit of instance XML but
should not be needed as you would not throw away working computer just
because OS decided to not support it's method of booting.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: The future of legacy BIOS support in Fedora.

[Marcin Juszkiewicz]

W dniu 30.06.2020 o 15:34, Jóhann B. Guðmundsson pisze:
> Given Hans proposal [1] introduced systemd/grub2/Gnome upstream
> changes it beg the question if now would not be the time to stop
> supporting booting in legacy bios mode and move to uefi only
> supported boot which has been available on any common intel based x86
> platform since atleast 2005.

Will you provide replacement for laptop I bought in 2013? Still has some
use, runs Fedora 31 just fine. BIOS mode only.

My other PC at home is BIOS mode only too. Sure, it is FX-6300 so quite
old but with some hard drives and 16GB of ram it has a use.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: armv7l status?

[Marcin Juszkiewicz]

W dniu 14.05.2020 o 14:34, Florian Weimer pisze:
> Just to be clear here, armhfp is *not* the common denominator of all
> 32-bit Arm architectures.  It does not cover the overall architecture in
> the sense that is compatible to with everything out there.  (I'm not
> sure if that is even possible.)  Fedora's 32-bit Arm requirements have
> always been fairly advanced, resulting in fewer compatible devices than
> other Linux distributions.

armhfp (Fedora, CentOS) is same as armhf (Debian, Ubuntu) as this was
discussed years ago in a group of ARM distro developers when there was a
need for v7 target.

armhf(p) == armv7 vfp3-d16, no neon

There are armv7 cpus with vfp4, armv7 with vfp3-d32, almost all armv7
chips nowadays have neon. And all them are compatible with armhf distros.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: What CPU extensions can we assume are available by arch?

[Marcin Juszkiewicz]

W dniu 22.04.2020 o 14:52, Florian Weimer pisze:
>> At this time upstream only supports AVX/AVX2/NEON, but if they did
>> add support for SVE on aarch64, can I use it?

> No.  I don't think the builders support it yet.

You can assume NEON on aarch64 as it is mandatory part. SVE is in one
or two cpus so far so you can not assume it.

On armhfp you have nothing. Builders have NEON but there were some
armv7 cpus without NEON...
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Announcing start of DNF 5 development

[Marcin Juszkiewicz]

W dniu 06.03.2020 o 02:57, Neal Gompa pisze:
> The database has been synchronized since Fedora 24. However, the
> caches are not, and that *does* need to be fixed.

And when user calls dnf let it use system cache by default...


17:38 (0s) hrw@puchatek:~$ time sudo dnf info nano
[
 fetching all repo data...
]
Dostępne pakiety
Nazwa: nano
Wersja   : 4.3
Wydanie  : 3.fc31
Architektura : x86_64
Rozmiar  : 640 k
Źródło   : nano-4.3-3.fc31.src.rpm
Repozytorium : updates
Podsumowanie : A small text editor
Adres URL: https://www.nano-editor.org
Licencja : GPLv3+
Opis : GNU nano is a small and friendly text editor.


real0m49,066s
user0m21,141s
sys 0m1,131s
17:38 (49s) hrw@puchatek:~$ time sudo dnf info nano
Ostatnio sprawdzono ważność metadanych: 0:00:09 temu w dniu pią, 6 mar 2020, 
17:38:55.
Dostępne pakiety
Nazwa: nano
Wersja   : 4.3
Wydanie  : 3.fc31
Architektura : x86_64
Rozmiar  : 640 k
Źródło   : nano-4.3-3.fc31.src.rpm
Repozytorium : updates
Podsumowanie : A small text editor
Adres URL: https://www.nano-editor.org
Licencja : GPLv3+
Opis : GNU nano is a small and friendly text editor.


real0m1,542s
user0m1,368s
sys 0m0,142s
17:39 (2s) hrw@puchatek:~$ time dnf info nano
[
 fetching all repo data...
]
Dostępne pakiety
Nazwa: nano
Wersja   : 4.3
Wydanie  : 3.fc31
Architektura : x86_64
Rozmiar  : 640 k
Źródło   : nano-4.3-3.fc31.src.rpm
Repozytorium : updates
Podsumowanie : A small text editor
Adres URL: https://www.nano-editor.org
Licencja : GPLv3+
Opis : GNU nano is a small and friendly text editor.


real0m56,689s
user0m21,374s
sys 0m1,130s
17:40 (57s) hrw@puchatek:~$ 

I have never understood a need for per-user copy of repo metadata.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Announcing start of DNF 5 development

[Marcin Juszkiewicz]

W dniu 04.03.2020 o 19:03, Daniel Mach pisze:
> Hello everyone, I'm pleased to announce start of DNF 5 development.

> microdnf
 > Microdnf is becoming important because it's part of
> many containers due to its small footprint.

[root@puchatek hrw]# ldd /bin/microdnf |wc -l
70

hrw@j13-qrep-04:ceph-12.2.11$ ldd /usr/bin/apt|wc -l
20

Are there plans for picodnf then? Or cutting amount of 
libraries used by microdnf?

My problem with DNF is Python. There is a huge amount of
packages which need to be in proper state to be able to use
dnf. I remember when I did some experiments with RHEL7 and
managed to get to the point where 'yum' was unable to help
as Python was broken.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

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

[Marcin Juszkiewicz]

W dniu 04.03.2020 o 16:33, Marcin Juszkiewicz pisze:
> W dniu 04.03.2020 o 16:24, Miroslav Suchý pisze:
>> Do you want to make Fedora 32 better? Please spend 1 minute of your time and 
>> try to run:
>>
>>   # Run this only if you use default Fedora modules
>>   # next time you run any DNF command default modules will be enabled again
>>   sudo dnf module reset '*'
>>
>>   sudo dnf --releasever=32 --setopt=module_platform_id=platform:f32 \
>> --enablerepo=updates-testing --enablerepo=updates-testing-modular \
>> distro-sync
>>
> 
>  Problem: package moodbar-0.1.2-19.fc29.x86_64 requires 
> libgstbase-0.10.so.0()(64bit), but none of the providers can be installed
>   - package moodbar-0.1.2-19.fc29.x86_64 requires 
> libgstreamer-0.10.so.0()(64bit), but none of the providers can be installed
>   - gstreamer-0.10.36-24.fc31.x86_64 does not belong to a distupgrade 
> repository
>   - problem with installed package moodbar-0.1.2-19.fc29.x86_64
> 
> Removed moodbar and next try was fine.

Looked closer - there are six downgrades:

Instalowanie poprzedniej wersji:
 firefox   x86_64 72.0.2-3.fc32fedora   98 M
 java-1.8.0-openjdk-headless
   x86_64 1:1.8.0.242.b06-0.0.ea.fc32
   fedora   32 M
 kf5-kirigami2 x86_64 5.67.0-1.fc32fedora  248 k
 libarchivex86_64 3.4.0-2.fc32 fedora  388 k
 libarchive-devel  x86_64 3.4.0-2.fc32 fedora  124 k
 qqc2-desktop-stylex86_64 5.67.0-1.fc32fedora  100 k

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

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

[Marcin Juszkiewicz]

W dniu 04.03.2020 o 16:24, Miroslav Suchý pisze:
> Do you want to make Fedora 32 better? Please spend 1 minute of your time and 
> try to run:
> 
>   # Run this only if you use default Fedora modules
>   # next time you run any DNF command default modules will be enabled again
>   sudo dnf module reset '*'
> 
>   sudo dnf --releasever=32 --setopt=module_platform_id=platform:f32 \
> --enablerepo=updates-testing --enablerepo=updates-testing-modular \
> distro-sync
> 

 Problem: package moodbar-0.1.2-19.fc29.x86_64 requires 
libgstbase-0.10.so.0()(64bit), but none of the providers can be installed
  - package moodbar-0.1.2-19.fc29.x86_64 requires 
libgstreamer-0.10.so.0()(64bit), but none of the providers can be installed
  - gstreamer-0.10.36-24.fc31.x86_64 does not belong to a distupgrade repository
  - problem with installed package moodbar-0.1.2-19.fc29.x86_64

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

Re: Downgrading from rawhide

[Marcin Juszkiewicz]

W dniu 25.02.2020 o 16:09, Christophe de Dinechin pisze:
> Is there any documented procedure to safely downgrade from rawhide
> to the latest release?
> 
> I tried
> 
> # dnf update --releasever=32 fedora-release 
> # dnf distro-sync --allowerasing --skip-broken
> 
> Does something like that have any chance of working? At first sight,
>  it seems to be somewhat successful.

I moved from rawhide to F24 few years ago [1]. Took some time but
was doable. There can be some extra steps needed than just those two
you listed.


1. 
https://marcin.juszkiewicz.com.pl/2016/09/12/downgrading-fedora-rawhide-fedora-24/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

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

[Marcin Juszkiewicz]

W dniu 17.09.2019 o 08:55, Zbigniew Jędrzejewski-Szmek pisze:
> On Tue, Sep 17, 2019 at 08:33:49AM +0200, Marcin Juszkiewicz wrote:
>> W dniu 11.09.2019 o 14:54, Miroslav Suchý pisze:
>>> Do you want to make Fedora 31 better? 
>>
>> I migrated to F31 beta some time ago. Today decided to 
>> go with 'dnf distro-sync' instead of usual 'dnf update'
>> command:
>>
>>  Problem: problem with installed package kf5-ktexteditor-5.61.0-1.fc31.x86_64
>>   - package kf5-ktexteditor-5.61.0-1.fc31.x86_64 requires 
>> libgit2.so.28()(64bit), but none of the providers can be installed
>>   - libgit2-0.28.2-3.fc31.x86_64 does not belong to a distupgrade repository
>>   - package libgit2-0.28.2-2.module_f31+5411+fa1856a4.x86_64 is excluded
>>   - package libgit2-0.28.3-1.fc31.x86_64 is excluded
>>   - package libgit2-0.28.2-3.fc31.x86_64 is excluded
> 
> Does 'dnf module reset libgit2' fix the issue?
> (See https://bugzilla.redhat.com/show_bug.cgi?id=1747408.)

Yes. Thanks!

Last metadata expiration check: 0:10:30 ago on wto, 17 wrz 2019, 08:53:50.
Dependencies resolved.
===
 Package Arch  Version
Repository  Size
===
Downgrading:
 hawtjni-runtime noarch1.16-2.module_f28+3939+dc18cd75
updates-testing-modular 42 k
 jansi   noarch1.17.1-1.module_f28+3939+dc18cd75  
updates-testing-modular 78 k
 jansi-nativex86_641.7-7.module_f28+3939+dc18cd75 
updates-testing-modular 73 k
 javamailnoarch1.5.2-7.module_f28+3872+5b76729e   
updates-testing-modular634 k
 libgit2 x86_640.28.2-2.module_f31+5411+fa1856a4  
updates-testing-modular451 k
 ninja-build x86_641.9.0-1.module_f31+3361+bdb2aa23   
updates-testing-modular126 k
 slf4j   noarch1.7.25-4.module_f28+3939+dc18cd75  
updates-testing-modular 76 k
 xalan-j2noarch2.7.1-38.module_f28+3872+5b76729e  
updates-testing-modular1.9 M
 xerces-j2   noarch2.11.0-34.module_f28+3872+5b76729e 
updates-testing-modular1.2 M
 xml-commons-apisnoarch1.4.01-25.module_f28+3872+5b76729e 
updates-testing-modular233 k
 xml-commons-resolvernoarch1.2-26.module_f28+3872+5b76729e
updates-testing-modular114 k
Enabling module streams:
 libgit2   0.28 
  

Transaction Summary
===
Downgrade  11 Packages

Total download size: 4.8 M
Is this ok [y/N]: 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

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

[Marcin Juszkiewicz]

W dniu 11.09.2019 o 14:54, Miroslav Suchý pisze:
> Do you want to make Fedora 31 better? 

I migrated to F31 beta some time ago. Today decided to 
go with 'dnf distro-sync' instead of usual 'dnf update'
command:

 Problem: problem with installed package kf5-ktexteditor-5.61.0-1.fc31.x86_64
  - package kf5-ktexteditor-5.61.0-1.fc31.x86_64 requires 
libgit2.so.28()(64bit), but none of the providers can be installed
  - libgit2-0.28.2-3.fc31.x86_64 does not belong to a distupgrade repository
  - package libgit2-0.28.2-2.module_f31+5411+fa1856a4.x86_64 is excluded
  - package libgit2-0.28.3-1.fc31.x86_64 is excluded
  - package libgit2-0.28.2-3.fc31.x86_64 is excluded

[root@puchatek puchatek-home]# rpm -qa|grep libgit
libgit2-0.28.2-3.fc31.x86_64
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

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

[Marcin Juszkiewicz]

W dniu 11.09.2019 o 14:54, Miroslav Suchý pisze:
> Do you want to make Fedora 31 better? Please spend 1 minute of your time and 
> try to run [*]:
> 
>   sudo dnf --releasever=31 --setopt=module_platform_id=platform:f31 
> --enablerepo=updates-testing distro-sync

Had to remove 'openshot' (FTBFS in rpmfusion) and then upgrade went fine.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: RFC: switch to uvesafb and drop openchrome in F31+

[Marcin Juszkiewicz]

W dniu 24.04.2019 o 02:46, Adam Jackson pisze:

> Finally, uvesafb only supports video devices that support VBE 2.0 or 
> higher. In principle, X's vesa driver supports any VBE implementation
> at all. I'm not convinced this is a real issue for us though. VBE 2.0
> dates to 1994, and I have maybe one pre-2.0 video card in my
> collection of old weird junk.
Pure curiosity: which gpus are in any use nowadays? Other than AMD,
Intel, NVidia ones.

Probably some server onboard ones only. Lot of graphic cards got dropped
in past already. Matrox ones for example.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Donate 1 minute of your time to test upgrades from F29 to F30

[Marcin Juszkiewicz]

W dniu 01.03.2019 o 13:28, Miroslav Suchý pisze:
> Dne 01. 03. 19 v 12:59 Marcin Juszkiewicz napsal(a):
>> My system was Fedora 19 when first time I installed Fedora. Now I
>> have packages from each release from F20 to F29 ;d
> 
> In fedora-upgrade(8) I run
> 
> package-cleanup --orphans | grep -v kernel
> 
> which:
> 
> --orphans List installed packages which are not available from
> currently configured repositories.  Maps to dnf repoquery --extras.
In case someone tries to run it - do yourself a favour and do 'dnf
update' first. Tool lists not updated packages as orphans.

Went from 215 to 85 on my system.

Anyway it is quite dangerous tool as it lists also all out-of-fedora
packages as orphans. Copr ones, rpmfusion ones etc.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Donate 1 minute of your time to test upgrades from F29 to F30

[Marcin Juszkiewicz]

W dniu 28.02.2019 o 10:22, Miroslav Suchý pisze:
> Do you want to make Fedora 30 better? Please spend 1 minute of your time and 
> try to run:
> 
>   sudo dnf --releasever=30 --setopt=module_platform_id=platform:f30 
> --enablerepo=updates-testing distro-sync

On my system it had 13 problems, 3 of them related to rpmfusion. So I did 'dnf 
update' first.

Now it says (5, 8, 9 were rpmfusion related):

 Problem 1: package mbox2eml-0.1.2-17.fc29.x86_64 requires 
libboost_filesystem.so.1.66.0()(64bit), but none of the providers can be 
installed
  - boost-filesystem-1.66.0-14.fc29.x86_64 does not belong to a distupgrade 
repository
  - problem with installed package mbox2eml-0.1.2-17.fc29.x86_64

 Problem 2: package python2-oslo-i18n-3.19.0-1.fc29.noarch requires 
python-oslo-i18n-lang = 3.19.0-1.fc29, but none of the providers can be 
installed
  - python-oslo-i18n-lang-3.19.0-1.fc29.noarch does not belong to a distupgrade 
repository
  - problem with installed package python2-oslo-i18n-3.19.0-1.fc29.noarch

 Problem 3: package python2-oslo-utils-3.35.1-1.fc29.noarch requires 
python-oslo-utils-lang = 3.35.1-1.fc29, but none of the providers can be 
installed
  - python-oslo-utils-lang-3.35.1-1.fc29.noarch does not belong to a 
distupgrade repository
  - problem with installed package python2-oslo-utils-3.35.1-1.fc29.noarch

 Problem 4: package python2-rpkg-1.57-6.fc29.noarch requires rpkg-common = 
1.57-6.fc29, but none of the providers can be installed
  - rpkg-common-1.57-6.fc29.noarch does not belong to a distupgrade repository
  - problem with installed package python2-rpkg-1.57-6.fc29.noarch

 Problem 6: package system-config-date-1.10.9-2.fc24.noarch requires 
python-slip >= 0.2.21, but none of the providers can be installed
  - python2-slip-0.6.4-12.fc29.noarch does not belong to a distupgrade 
repository
  - problem with installed package system-config-date-1.10.9-2.fc24.noarch

 Problem 7: package system-config-services-0.111.4-2.fc24.noarch requires 
python-slip-dbus >= 0.2.8, but none of the providers can be installed
  - python2-slip-dbus-0.6.4-12.fc29.noarch does not belong to a distupgrade 
repository
  - problem with installed package system-config-services-0.111.4-2.fc24.noarch

 Problem 10: package python3-flake8-3.6.0-2.fc30.noarch requires 
python3.7dist(pycodestyle) < 2.5.0, but none of the providers can be installed
  - problem with installed package python3-flake8-3.5.0-6.fc29.noarch
  - python3-pycodestyle-2.4.0-3.fc29.noarch does not belong to a distupgrade 
repository
  - python3-flake8-3.5.0-6.fc29.noarch does not belong to a distupgrade 
repository

 Problem 11: cannot install both python-oslo-i18n-lang-3.19.0-3.fc30.noarch and 
python-oslo-i18n-lang-3.19.0-1.fc29.noarch
  - package python3-oslo-i18n-3.19.0-3.fc30.noarch requires 
python-oslo-i18n-lang = 3.19.0-3.fc30, but none of the providers can be 
installed
  - package python2-oslo-i18n-3.19.0-1.fc29.noarch requires 
python-oslo-i18n-lang = 3.19.0-1.fc29, but none of the providers can be 
installed
  - problem with installed package python3-oslo-i18n-3.19.0-1.fc29.noarch
  - package python2-glanceclient-1:2.10.0-1.fc29.noarch requires 
python2-oslo-i18n >= 3.15.3, but none of the providers can be installed
  - python3-oslo-i18n-3.19.0-1.fc29.noarch does not belong to a distupgrade 
repository
  - problem with installed package python2-glanceclient-1:2.10.0-1.fc29.noarch

 Problem 12: cannot install both python-oslo-utils-lang-3.35.1-3.fc30.noarch 
and python-oslo-utils-lang-3.35.1-1.fc29.noarch
  - package python3-oslo-utils-3.35.1-3.fc30.noarch requires 
python-oslo-utils-lang = 3.35.1-3.fc30, but none of the providers can be 
installed
  - package python2-oslo-utils-3.35.1-1.fc29.noarch requires 
python-oslo-utils-lang = 3.35.1-1.fc29, but none of the providers can be 
installed
  - problem with installed package python3-oslo-utils-3.35.1-1.fc29.noarch
  - package python2-oslo-serialization-2.24.0-1.fc29.noarch requires 
python2-oslo-utils >= 3.33.0, but none of the providers can be installed
  - python3-oslo-utils-3.35.1-1.fc29.noarch does not belong to a distupgrade 
repository
  - problem with installed package 
python2-oslo-serialization-2.24.0-1.fc29.noarch

Then I removed 'system-config-date system-config-services' from system.

My system was Fedora 19 when first time I installed Fedora. Now I have packages 
from 
each release from F20 to F29 ;d
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Donate 1 minute of your time to test upgrades from F29 to F30

[Marcin Juszkiewicz]

W dniu 28.02.2019 o 10:22, Miroslav Suchý pisze:
> Do you want to make Fedora 30 better? Please spend 1 minute of your time and 
> try to run:
> 
>   sudo dnf --releasever=30 --setopt=module_platform_id=platform:f30 
> --enablerepo=updates-testing distro-sync
> 
> If you get this prompt:
> 
>   ...
>   Total download size: XXX M
>   Is this ok [y/N]:
> 
> you can answer N and nothing happens, no need to test the real upgrade. 
> Upgrades will be fine for you.
> 
> But very likely you get some dependency problem now. In that case please 
> report it against appropriate package.

Worth doing 'sudo dnf update' first as some of issues could be already
solved. Also check bugzilla before reporting.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: [HEADS UP] Ceph-14.x.x, dropping 32-bit archs

[Marcin Juszkiewicz]

W dniu 05.12.2018 o 14:45, Kaleb S. KEITHLEY pisze:
> On 12/5/18 8:34 AM, Dan Horák wrote:
>> On Wed, 5 Dec 2018 14:23:49 +0100
>> Marcin Juszkiewicz  wrote:
>>
>>> W dniu 05.12.2018 o 14:14, Kaleb S. KEITHLEY pisze:
>>>
>>>> Ceph 14.x.x (Nautilus) will no longer be built on i686 and armv7hl
>>>> archs starting in fedora-30/rawhide.
>>>> The upstream project doesn't support it. The armv7hl builders don't
>>>> have enough memory (or address space) to build some components.
>>> BTW - how much memory is needed to build Ceph 14?

> More — apparently — than the armv7hl builders have. :-) branto may know.

Random Fedora armhf builder hardware info:

---
CPU info:
Architecture:armv7l
Byte Order:  Little Endian
CPU(s):  4
On-line CPU(s) list: 0-3
Thread(s) per core:  1
Core(s) per socket:  4
Socket(s):   1
Model:   1
Model name:  ARMv7 Processor rev 1 (v7l)
BogoMIPS:100.00
Flags:   half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva 
idivt vfpd32 lpae evtstrm


Memory:
  totalusedfree  shared  buff/cache   available
Mem:   24929616  10309224375448 348  45107624524500
Swap:  18869244   2134818847896


Storage:
Filesystem  Size  Used Avail Use% Mounted on
/dev/vda2   135G  5.7G  122G   5% /
---

Seriously 24 GB of ram + 18 GB of swap is not enough to build ceph? That's
more real memory than x86-64 builder have (15 387 432 ram + 134 216 700 swap).

I understand "we drop because upstream does not care about 32bit" reason.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: [HEADS UP] Ceph-14.x.x, dropping 32-bit archs

[Marcin Juszkiewicz]

W dniu 05.12.2018 o 14:14, Kaleb S. KEITHLEY pisze:

> Ceph 14.x.x (Nautilus) will no longer be built on i686 and armv7hl archs
> starting in fedora-30/rawhide.

> The upstream project doesn't support it. The armv7hl builders don't have
> enough memory (or address space) to build some components.

BTW - how much memory is needed to build Ceph 14?
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: %{valgrind_arches}

[Marcin Juszkiewicz]

W dniu 07.08.2018 o 15:12, Florian Weimer pisze:
> On 08/06/2018 09:58 PM, Marcin Juszkiewicz wrote:
>>  From what I remember there is no architecture supported by Fedora
>> without Valgrind support. We got rid of s390 (32bit) and risc-v does not
>> count yet.
> 
> valgrind support is not monotonic because architectures evolve.  If we
> move the architecture baseline, we could well lose valgrind support
> again.  This is true if we moved i686 from SSE2 to AVX2 (clearly
> hypothetical) or s390x from zEC12 to z13 (much less so).

> So I think %{valgrind_arches} clearly has its place going forward.

Sorry for not being clear. I am all in favour of using
${valgrind_arches} wherever it is required.

My note was more directed to packagers to mention that it is now widely
supported tool covering all Fedora architectures (but may change so
${valgrind_arches} is something to keep in specs instead of using
"%ifarch arch1 arch2 arch3").
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/6EIKV2GSZVES4HSLGCOBEVIZRR6BVLYT/

Re: %{valgrind_arches}

[Marcin Juszkiewicz]

W dniu 05.08.2018 o 16:36, Jeff Johnson pisze:
> So you are recommending using 14 lines (with comments) of spec file
> goop that uses 2 %ifarch build section tests in order to set/unset a
> macro.
> 
> There's further baggage in spec files needed to add a BR, pass an
> option to configure, add libraries to link, etc

Spec files are often wrote in 'I do not know other archs than x86' way.
I remember going through valgrind support for aarch64 few years ago
where changes to upstream valgrind were simple but all those packages
where %{valgrind_archs} was done in "%ifarch x86_64 i686" way required
patching and then patching...

From what I remember there is no architecture supported by Fedora
without Valgrind support. We got rid of s390 (32bit) and risc-v does not
count yet.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/NJJBWIIHZDXNHL67YK7QV7RY7YNLIMUV/

Re: Would be possible to add freerdp2 package only for EPEL?

[Marcin Juszkiewicz]

W dniu 29.05.2018 o 01:21, Kevin Fenzi pisze:
> Nope. koji operates on source packages. If it sees a 'freerdp' source
> package in epel that will completely and totally override any freerdp
> package in epel and any subpackages it has will be ignored. The name
> must be different between epel and rhel to avoid this. ;(

I thought that this would not be a problem as epel is built on Fedora
infra which is not same as rhel one.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/PEGD3G3D5DRWC7JKNHE2AFGHZ3LP7ZZF/

Re: Would be possible to add freerdp2 package only for EPEL?

[Marcin Juszkiewicz]

W dniu 28.05.2018 o 13:22, Ondrej Holy pisze:
> Unfortunately, EPEL branch for freerdp can't be simply created due to
> package name conflict. Would be possible to add freerdp2 package only for
> EPEL?

Can not you reuse existing freerdp and just produce 'freerdp2' package
for EPEL7?

Kind of:

# information why package change for epel7
%if ${rhel} && ${rhel} == 7
Package: freerdp2
%else
Package: freerdp
%endif

That way there is still one package to maintain and all Fedora changes
can go into EPEL7 in an easy way.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/GQYG2LBCJS7NZK6BTRDQH65H7WDUEW3U/

Re: Announcing DNF 3 development

[Marcin Juszkiewicz]

W dniu 26.03.2018 o 10:16, Tom Hughes pisze:
> On 26/03/18 09:06, Marcin Juszkiewicz wrote:

>> Will it FINALLY use one copy of metadata for all system users?
> 
> Do you have a proposal as to how that might be possible in a
> secure way?

Use. Not download. And inform (like always) how old that data is.

>> I do not see how fetching megabytes of metadata is better than using
>> copy present in /var/cache/dnf/ directory.
> 
> Well it could just use the cached copy sure, but if it was out of
> date then it wouldn't be able to update it?

Then it is out-of-date. But still is. And not everyone runs rawhide to
make it a difference when metadata is few days old.

>> It is faster to enter long password to use sudo than to wait until dnf
>> fetch useless copy of metadata.
> 
> Agreed, which is why I always run dnf under sudo even for query
> operations.

I hate having to do that. Also dislike fact that if I do not do that
then have to wait and wait and wait until it finally fetch metadata to
show me result.

DNF started as user can not install packages so why it can not just use
systemwide metadata?

>> Debian has APT. APT uses one copy of metadata. Be wise. Like Debian.
> 
> Do we know how? Do they just not allow non-root users to get up
> to date data, or do they do something cleverer?

APT has separate command for updating metadata. YUM/DNF tries to do that
every time they think that metadata is too old.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Announcing DNF 3 development

[Marcin Juszkiewicz]

W dniu 22.03.2018 o 13:40, Daniel Mach pisze:
> We are pleased to announce that development of DNF 3 has started. This
> version is focused on performance improvements, new API and consolidating
> the whole software management stack.
> 
> Please read more details on our blog:
> https://rpm-software-management.github.io/announcement/2018/03/22/dnf-3-announcement/

Will it FINALLY use one copy of metadata for all system users?

I do not see how fetching megabytes of metadata is better than using
copy present in /var/cache/dnf/ directory.

It is faster to enter long password to use sudo than to wait until dnf
fetch useless copy of metadata.

10:01 (1s) hrw@puchatek:~$ LANGUAGE=C LANG=C COLUMNS=60  dnf list nano
Spotify (negativo17) 31 kB/s |  11 kB 00:00
Fedora 27 - x86_64 - Update 8.4 MB/s |  21 MB 00:02
Fedora 27 - x86_64   15 MB/s |  58 MB 00:03
Google Chrome (stable)   57 kB/s | 3.7 kB 00:00
google-earth 72 kB/s | 4.7 kB 00:00
RPM Fusion for Fedora 27 -  984 kB/s | 351 kB 00:00
RPM Fusion for Fedora 27 -  1.3 MB/s | 717 kB 00:00
RPM Fusion for Fedora 27 -   50 kB/s |  87 kB 00:01
RPM Fusion for Fedora 27 -  128 kB/s | 163 kB 00:01
Skype Repository 40 kB/s | 1.8 kB 00:00
Last metadata expiration check: 0:00:00 ago on Mon Mar 26 10:03:01 2018.
Available Packages
nano.x86_64   2.8.7-1.fc27fedora
10:02 (40s) hrw@puchatek:~$

40 seconds just because of good download speed.


Debian has APT. APT uses one copy of metadata. Be wise. Like Debian.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: [UPDATE] Re: Mass package change (python2- binary package renaming)

[Marcin Juszkiewicz]

W dniu 28.08.2017 o 14:31, Zbigniew Jędrzejewski-Szmek pisze:
> On Mon, Aug 28, 2017 at 02:11:16PM +0200, Marcin Juszkiewicz wrote:
>> W dniu 12.08.2017 o 17:15, Zbigniew Jędrzejewski-Szmek pisze:
>>> atomic-reactor/   ftbfs (AttributeError: module 'docker' has no 
>>> attribute 'Client')
>>
>> Looks like it uses 'docker-py' rather than 'docker' one which is the one
>>  other projects migrated to.
>>
>> docker.Client -> docker.APIClient rename happened but I do not know were
>> there other changes.
> 
> Yeah, it probably isn't even too hard to fix, but it should be done by the
> maintainers of the package. This isn't something for a drive-by contributor.

Looks like Adam Miller already sorted that out in rpms/atomic-reactor
repo ;D
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: [UPDATE] Re: Mass package change (python2- binary package renaming)

[Marcin Juszkiewicz]

W dniu 12.08.2017 o 17:15, Zbigniew Jędrzejewski-Szmek pisze:
> atomic-reactor/   ftbfs (AttributeError: module 'docker' has no 
> attribute 'Client')

Looks like it uses 'docker-py' rather than 'docker' one which is the one
 other projects migrated to.

docker.Client -> docker.APIClient rename happened but I do not know were
there other changes.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: RPM macros - case insensitive since Fedora 27 (maybe Fedora 26)

[Marcin Juszkiewicz]

W dniu 24.05.2017 o 17:32, Zdenek Dohnal pisze:
> Hi,
> 
> I was doing rebase for gutenprint pre-release in recent rawhide (fc27)
> and I couldn't build it because I had %VERSION macro defined by myself
> and it got rewritten by default macro %version. That indicates rpm
> macros have been case insensitive since fc27 (colleague told me the same
> situation is in fc26 too, but I encountered it in fc27).
> 
> Would anyone mind explaining why such change was introduced for RPM
> macros, please? IMHO I do not think it is good idea, because it shrinks
> group of useful names for packager defined RPM macros.

I do wonder why such names was used at all? %gp_version is just 3
characters longer, looks local to spec file and do not conflict.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: future of official optical media support in Fedora

[Marcin Juszkiewicz]

W dniu 06.12.2016 o 14:43, Kamil Paral pisze:

> All of that is, of course, motivated by trying to spend QA time more
> effectively. You can see the current coverage e.g. in this table [2],
> overall we burn 6 DVDs and perform 12 optical installation (BIOS +
> UEFI) for every release candidate published. We allow non-complete
> (yet still substantial) coverage for Alpha and Beta, but 100%
> coverage for Final for each candidate compose. That is quite time
> consuming, both burning and installation from optical media take a
> long time, it requires bare metal testing, and we can't use the
> machines for anything else during that time.

Why not boot VM with virtual optical drive? You can choose BIOS/UEFI,
32/64bit and do not require bare metal hardware for it.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Recommended upgrade procedure for >1 release upgrades

[Marcin Juszkiewicz]

On 18/11/16 05:50, Stephen Gallagher wrote:

GNOME Software uses PackageKit and both PackageKit and DNF these days
use the same underlying dependency resolvers. So they're a lot closer
than they used to be.


Thanks.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Recommended upgrade procedure for >1 release upgrades

[Marcin Juszkiewicz]

W dniu 18.11.2016 o 12:49, Michael Catanzaro pisze:
> On Fri, 2016-11-18 at 05:37 +, Sérgio Basto wrote:
>> but GNOME Software use dnf-plugin-system-upgrade ? if yes , since
>> then
>> we have dnf-plugin-system-upgrade should be safe offer ii 
> 
> No, GNOME Software does not use dnf and never will.

I knew that packaging in Fedora is one step from madness but now I see
that it is one step above madness...

dnf, packagekit, gnome software... how many other tools try to work as
package upgrading tools in Fedora?

Or does gnome software uses packagekit? Then why PK does not use dnf?
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Missing qemu deps on ppc64le

[Marcin Juszkiewicz]

W dniu 10.10.2016 o 16:34, Paolo Bonzini pisze:
> On 10/10/2016 13:30, Sandro Bonazzola wrote:

>> just seen:
>> DEBUG util.py:421:  Error: Package:
>> 2:qemu-system-aarch64-2.6.1-1.fc24.ppc64le (updates)
>> DEBUG util.py:421: Requires: edk2-aarch64
>> DEBUG util.py:421:  Error: Package:
>> 2:qemu-system-x86-2.6.1-1.fc24.ppc64le (updates)
>> DEBUG util.py:421: Requires: edk2-ovmf
>>
>> While installing qemu on ppc64le Fedora.
>> Any ETA on fixing it?
> 
> The reason for this is documented in edk2.spec.
> 
> # actual firmware builds support cross-compiling.  edk2-tools
> # in theory should build everywhere without much trouble, but
> # in practice the edk2 build system barfs on archs it doesn't know
> # (such as ppc), so lets limit things to the known-good ones.
> ExclusiveArch:  %{ix86} x86_64 %{arm} aarch64
> 
> I suppose that QEMU should not require edk2 on architectures other than
> ARM and x86.

edk2-* packages are noarch. Secondary architectures should imho import
built binary packages into repository.

Qemu allows you to emulate several architectures on many architectures -
basically any Fedora supported one (primary or secondary) on any of them.

qemu-system-{x86,aarch64,arm,x86-64} may use UEFI binary to run VM.


Some time ago I was using virt-manager to test aarch64, arm, ppc64,
ppc64le, x86, x86-64 VMs on aarch64 and x86-64 hosts.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F26 Self Contained Change: Jekyll

[Marcin Juszkiewicz]

W dniu 10.10.2016 o 10:30, Jan Kurik pisze:
> = Proposed Self Contained Change: Jekyll =
> https://fedoraproject.org/wiki/Changes/Jekyll

Since when adding new package requires Change proposal?
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Versioning the Packaging Guidelines

[Marcin Juszkiewicz]

W dniu 09.09.2016 o 14:25, gil pisze:
>> Could we learn anything from this? Fedora is not a rolling
>> distribution, but the guidelines are. Would it be a good idea to
>> actually provide versions of the guidelines? To track the last version
>> checked in the packages?
>>
>> If not for anything else., it would certainly make the life of
>> fedora-review maintainers easier.

> to me it seems the opposite ...

As long time Debian user (who played with packaging too) I would say
that updating package to newest guidelines was described well in
guidelines changelog. Especially when package is well maintained it
often just meant "updated to latest standards. no changes required".
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: aarch64 machine for packagers?

[Marcin Juszkiewicz]

21.08.2016 00:17 "Jerry James"  napisał(a):

> Thanks for the information, Kevin.  I guess I'll have to go the QEMU
> route after all, then.

Try http://linaro.cloud/ as well.
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Long live YUM!

[Marcin Juszkiewicz]

W dniu 08.08.2016 o 12:02, Christopher Meng pisze:
> On Monday, 8 August 2016, Marcin Juszkiewicz 

>> 11:53 root@puchatek:~# LANGUAGE=C dnf remove yum
>> Dependencies resolved.
>> 
>>  Package  ArchVersion   Repository
>>Size
>> 
>> Removing:
>>  bodhi-client noarch  0.9.12.2-5.fc25   @rawhide   27 k
>>  brewkoji noarch  1.8-1.fc17@System10 k
> 
> 
> Fedora 17?

I do not reinstall system every release.

12:26 root@puchatek:hrw# for f in `seq 16 26`;do printf "$f\t"; rpm
-qa|grep fc$f|wc -l;done
16  0
17  1
18  0
19  2
20  3
21  5
22  18
23  11
24  1009
25  1845
26  427

--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Long live YUM!

[Marcin Juszkiewicz]

I updated my system today and noticed that one of updated packages was
"yum". Yes, that package manager tool we were supposed to obsolete with
switch to "dnf" few releases ago.

So I decided to remove it:

11:53 root@puchatek:~# LANGUAGE=C dnf remove yum
Dependencies resolved.

 Package  ArchVersion   Repository
   Size

Removing:
 bodhi-client noarch  0.9.12.2-5.fc25   @rawhide   27 k
 brewkoji noarch  1.8-1.fc17@System10 k
 createrepo   noarch  0.10.3-10.fc25@rawhide  301 k
 createrepo_c x86_64  0.10.0-5.fc25 @rawhide  150 k
 createrepo_c-libsx86_64  0.10.0-5.fc25 @rawhide  207 k
 drpm x86_64  0.3.0-3.fc25  @rawhide  142 k
 dumpet   x86_64  2.1-12.fc24   @rawhide   38 k
 fedora-packager  noarch  0.5.10.7-3.fc25   @rawhide   80 k
 fedpkg   noarch  1.24-4.fc25   @rawhide   87 k
 koji noarch  1.10.1-11.fc25@rawhide  1.1 M
 livecd-tools x86_64  1:23.3-2.fc25 @rawhide  147 k
 loraxx86_64  25.12-1.fc26  @rawhide  534 k
 lorax-templates-generic  x86_64  25.12-1.fc26  @rawhide  111 k
 mock noarch  1.2.18-2.fc25 @rawhide  1.2 M
 packagedb-clinoarch  2.13-2.fc25   @rawhide  222 k
 pyrpkg   noarch  1.46-2.fc25   @rawhide  434 k
 python-dockerfile-parse  noarch  0.0.5-5.fc25  @rawhide   67 k
 python-imgcreate x86_64  1:23.3-2.fc25 @rawhide  282 k
 python-kickstart noarch  2.31-1.fc25   @rawhide  1.7 M
 python-ordered-set   noarch  2.0.0-4.fc25  @rawhide   15 k
 python-osbs-client   noarch  0.24-2.fc25   @rawhide  429 k
 python2-deltarpm x86_64  3.6-17.fc25   @rawhide   44 k
 python2-iniparse noarch  0.4-20.fc25   @rawhide  113 k
 python2-pygpgme  x86_64  0.3-18.fc25   @rawhide  306 k
 python2-yubico   noarch  1.3.2-3.fc25  @rawhide  244 k
 python3-beaker   noarch  1.5.4-14.fc25 @rawhide  355 k
 python3-mako noarch  1.0.3-3.fc25  @rawhide  755 k
 pyusbnoarch  1.0.0-2.fc25  @rawhide  405 k
 rhpkgnoarch  1.18-2.fc20   @brew 125 k
 squashfs-tools   x86_64  4.3-12.fc24   @rawhide  380 k
 system-config-keyboard   noarch  1.4.0-10.fc25 @rawhide   40 k
 system-config-keyboard-base  noarch  1.4.0-10.fc25 @rawhide  469 k
 yum  noarch  3.4.3-510.fc25@rawhide  5.6 M
 yum-langpacksnoarch  0.4.5-3.fc24  @rawhide   66 k
 yum-utilsnoarch  1.1.31-510.fc25   @rawhide  334 k

Transaction Summary

Remove  35 Packages

Installed size: 16 M
Is this ok [y/N]: n
Operation aborted.


Are there plans to migrate tools/packages to stop depending on "yum" in
Fedora 25-26 cycles?
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Too fast karma on Bodhi updates

[Marcin Juszkiewicz]

W dniu 11.07.2016 o 10:59, Raphael Groner pisze:
>> W dniu 10.07.2016 o 18:00, Sayan Chowdhury pisze:
>> 
>> 
>> What about situation when maintainer X scratch built package Y, got
>> it tested by few people (let name them A, C, E, F) before
>> submitting it to stable-updates?
>> 
>> Once package enters stable-updates A, C, E, F give +1 to package as
>> it got built in exactly same environment as one they were testing.
> 
> Are you talking about secondary architectures?

No.
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Too fast karma on Bodhi updates

[Marcin Juszkiewicz]

W dniu 10.07.2016 o 18:00, Sayan Chowdhury pisze:

> I recently packaged and pushed an update for
> fedmsg-meta-fedora-infrastructure to bodhi and exactly 40 secs[1]
> later I got a +1 to the update. I am sure that testing a package
> surely takes more than 40 secs. This makes me really curious that are
> the packages really being tested before giving out the karma.

What about situation when maintainer X scratch built package Y, got it
tested by few people (let name them A, C, E, F) before submitting it to
stable-updates?

Once package enters stable-updates A, C, E, F give +1 to package as it
got built in exactly same environment as one they were testing.
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Wh{o,at} broke rawhide?

[Marcin Juszkiewicz]

W dniu 09.06.2016 o 00:18, gil pisze:

I have no idea why but most of your mails end in my spam folder ;(


Il 08/06/2016 21:15, Kevin Fenzi ha scritto:

On Wed, 8 Jun 2016 21:07:26 +0200
Marcin Juszkiewicz  wrote:



Any ideas (other than "switch to F24/Ubuntu/Debian/Umbaumba" ones)?



the latest is the better solution ...




3. Try another DE and see if the problem happens there?



who did you of bad kde?


And level of your answers probably answers why.
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Wh{o,at} broke rawhide?

[Marcin Juszkiewicz]

W dniu 08.06.2016 o 21:15, Kevin Fenzi pisze:
> On Wed, 8 Jun 2016 21:07:26 +0200
> Marcin Juszkiewicz  wrote:
>
>> I used 4.7-rc0.git3 kernel for few days. In the morning I did an
>> update to fresh rawhide and then fork() stopped forking.
>>
>> Thunderbird was crashing on start, Chrome refused to do anything,
>> Konsole greeted me with "fork() failed" messages when I needed new
>> tab.
>>
>> It is not a kernel fault as it happens under 4.6, 4.7-rc2, 4.7-rc0
>> ones.
>>
>> I downgraded Wine to 1.9.10 in meantime to check does Diablo III
>> works (it did not, while was working yesterday).
>>
>> Any ideas (other than "switch to F24/Ubuntu/Debian/Umbaumba" ones)?
>
> I'm not seeing that here (Although I haven't rebooted yet today).
>
> More information would be of help:

> 1. Check logs and see exactly what was updated. Do any of those things
> look suspect? glibc or kde base libs (since it sounds like you are in
> kde?)

glibc, kde-runtime, boost and many others as previous update was on 2nd
June. Reverting requires fetching all updates from koji as 
glibc 2.23.90-19 got GLIBC_2.24 symbol.

> 2. Check selinux avcs and/or boot/switch to permissive, do things start
> working then?

Nothing new in avcs.

> 3. Try another DE and see if the problem happens there?

XFCE session ends with monitor shutting down ;(

Pulseaudio ends with dummy outputs too.
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Wh{o,at} broke rawhide?

[Marcin Juszkiewicz]

I used 4.7-rc0.git3 kernel for few days. In the morning I did an update 
to fresh rawhide and then fork() stopped forking.


Thunderbird was crashing on start, Chrome refused to do anything, 
Konsole greeted me with "fork() failed" messages when I needed new tab.


It is not a kernel fault as it happens under 4.6, 4.7-rc2, 4.7-rc0 ones.

I downgraded Wine to 1.9.10 in meantime to check does Diablo III works 
(it did not, while was working yesterday).


Any ideas (other than "switch to F24/Ubuntu/Debian/Umbaumba" ones)?
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: DNF 1.1.8 and DNF-PLUGINS-CORE 0.1.20 Released

[Marcin Juszkiewicz]

W dniu 12.04.2016 o 11:20, Honza Šilhan pisze:

The new version of DNF and DNF-PLUGINS-CORE has been released.


Can someone update version in EPEL7?
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Support for PCLMUL, AVX, FMA, etc.

[Marcin Juszkiewicz]

W dniu 01.04.2016 o 22:32, Jerry James pisze:

I am one of the maintainers of the ntl package, which is used by some
numeric applications (e.g., Macaulay2 and sagemath).  Upstream
supports use of the PCLMUL instruction, the AVX instructions, and the
FMA instructions to speed up various computations.  We can't use any
of those in Fedora, since we have to support a baseline x86_64.


Note that FMA may affect precision so tests which base on float number 
can fail.

--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Chromium

[Marcin Juszkiewicz]

W dniu 16.03.2016 o 19:19, Tom Callaway pisze:

And of course:

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


qt5-qtwebengine contains chromium source code already so it may be good 
to check how it was packaged.

--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: [ANNOUNCE] Fedora support for Vulkan

[Marcin Juszkiewicz]

W dniu 16.02.2016 o 19:48, Adam Jackson pisze:

> Currently the repository includes the driver loader, as well as Intel's
> open source drivers for gen8+ (Broadwell, Cherryview, Skylake, Broxton
> and Kabylake) GPUs. The Intel drivers also have incomplete support for
> Ivybridge, Haswell, and Baytrail devices; I can vouch that the
> Ivybridge support is good enough to run the vkcube demo.

> Your favorite hardware driver or 3D game engine quite likely could use
> help in enabling a Vulkan port

Any info about Radeon support?

23:59 hrw@puchatek:~$ vulkaninfo
===
VULKAN INFO
===

Vulkan API Version: 1.0.3

INFO: [loader] Code 0 : Found manifest file 
/usr/share/vulkan/explicit_layer.d/VkLayer_unique_objects.json, version "1.0.0"
INFO: [loader] Code 0 : Found manifest file 
/usr/share/vulkan/explicit_layer.d/VkLayer_draw_state.json, version "1.0.0"
INFO: [loader] Code 0 : Found manifest file 
/usr/share/vulkan/explicit_layer.d/VkLayer_device_limits.json, version "1.0.0"
INFO: [loader] Code 0 : Found manifest file 
/usr/share/vulkan/explicit_layer.d/VkLayer_swapchain.json, version "1.0.0"
INFO: [loader] Code 0 : Found manifest file 
/usr/share/vulkan/explicit_layer.d/VkLayer_mem_tracker.json, version "1.0.0"
INFO: [loader] Code 0 : Found manifest file 
/usr/share/vulkan/explicit_layer.d/VkLayer_threading.json, version "1.0.0"
INFO: [loader] Code 0 : Found manifest file 
/usr/share/vulkan/explicit_layer.d/VkLayer_param_checker.json, version "1.0.0"
INFO: [loader] Code 0 : Found manifest file 
/usr/share/vulkan/explicit_layer.d/VkLayer_image.json, version "1.0.0"
INFO: [loader] Code 0 : Found manifest file 
/usr/share/vulkan/explicit_layer.d/VkLayer_object_tracker.json, version "1.0.0"
INFO: [loader] Code 0 : Found manifest file /etc/vulkan/icd.d/anv_icd.json, 
version "1.0.0"
Instance Extensions and layers:
===
Instance Extensions count = 4
VK_KHR_surface  : extension revision 25
VK_KHR_xcb_surface  : extension revision  5
VK_KHR_wayland_surface  : extension revision  4
VK_EXT_debug_report : extension revision  1

Instance Layers count = 9
VK_LAYER_GOOGLE_unique_objects (Google Validation Layer) Vulkan version 
1.0.3, layer version 1
VK_LAYER_GOOGLE_unique_objects Extensions   count = 0

VK_LAYER_LUNARG_draw_state (LunarG Validation Layer) Vulkan version 
1.0.3, layer version 1
VK_LAYER_LUNARG_draw_state Extensions   count = 1
VK_EXT_debug_report : extension revision  1

VK_LAYER_LUNARG_device_limits (LunarG Validation Layer) Vulkan version 
1.0.3, layer version 1
VK_LAYER_LUNARG_device_limits Extensionscount = 1
VK_EXT_debug_report : extension revision  1

VK_LAYER_LUNARG_swapchain (LunarG Validation Layer) Vulkan version 
1.0.3, layer version 1
VK_LAYER_LUNARG_swapchain Extensionscount = 1
VK_EXT_debug_report : extension revision  1

VK_LAYER_LUNARG_mem_tracker (LunarG Validation Layer) Vulkan version 
1.0.3, layer version 1
VK_LAYER_LUNARG_mem_tracker Extensions  count = 1
VK_EXT_debug_report : extension revision  1

VK_LAYER_LUNARG_threading (LunarG Validation Layer) Vulkan version 
1.0.3, layer version 1
VK_LAYER_LUNARG_threading Extensionscount = 1
VK_EXT_debug_report : extension revision  1

VK_LAYER_LUNARG_param_checker (LunarG Validation Layer) Vulkan version 
1.0.3, layer version 1
VK_LAYER_LUNARG_param_checker Extensionscount = 1
VK_EXT_debug_report : extension revision  1

VK_LAYER_LUNARG_image (LunarG Validation Layer) Vulkan version 1.0.3, 
layer version 1
VK_LAYER_LUNARG_image Extensionscount = 1
VK_EXT_debug_report : extension revision  1

VK_LAYER_LUNARG_object_tracker (LunarG Validation Layer) Vulkan version 
1.0.3, layer version 1
VK_LAYER_LUNARG_object_tracker Extensions   count = 1
VK_EXT_debug_report : extension revision  1

/builddir/build/BUILD/vulkan/demos/vulkaninfo.c:1183: failed with 
VK_ERROR_INITIALIZATION_FAILED
23:59 hrw@puchatek:~$ vkcube 
0 physical devices
Segmentation fault (core dumped)
23:59 hrw@puchatek:~$ lspci|grep VGA
01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Oland 
PRO [Radeon R7 240/340]
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: F24 Self Contained Change: System Python

[Marcin Juszkiewicz]

W dniu 10.02.2016 o 09:13, Colin Walters pisze:

The OpenEmbedded project has been doing this for quite a while:


Note that distributions built using OpenEmbedded are meant for storage 
limited devices.


Years ago I had to squeeze kernel, Python, gstreamer and working system 
into 16MB of flash. Used OE and final result was scary but working.


We even had X11 running from 14MB rootfs...
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Build root prepared by DNF is way larger

[Marcin Juszkiewicz]

W dniu 25.01.2016 o 17:03, Vít Ondruch pisze:

So it appears this thread was probably not enough. Which keeps us with
interesting state where mock by default does not install weak
dependencies where Koji installs them. It causes interesting issues already.


mock/koji not installing weak dependencies == anything wanting ruby 
being broken.


Reason: "ruby" suggests "rubypick" which suggests "ruby".

Packages buildrequire "ruby" but do not get "rubypick" installed (or if 
they are lucky they get) so are unable to find Ruby because there is no 
"/bin/ruby" executable.


https://bugzilla.redhat.com/show_bug.cgi?id=1300669 shows how it look on 
aarch64.


> Not sure if I should prepare my packages to be ready or not 

"rubypick" is yours ;D
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: New tbb in Rawhide

[Marcin Juszkiewicz]

W dniu 15.01.2016 o 23:14, Jerry James pisze:

I am going to build the latest version of tbb in Rawhide soon.



I have already done successful rebuilds of these packages in mock for
x86_64, so I don't expect any trouble.  Nevertheless, if a build fails,
I will look into it.


Please do check on secondary archs as well. {arm,ppc,s390}-koji works 
without any extra configuration needed.

--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: New scitech FAS and COPR group

[Marcin Juszkiewicz]

On środa, 6 stycznia 2016 09:31:01 CET Orion Poplawski wrote:
> I've created a "scitech" FAS and COPR group for the SciTech SIG
> (https://fedoraproject.org/wiki/Category:SciTech_SIG).  My immediate
> goal is to create some common repositories for updated builds of
> scientific software for EL7 (& 6).  My thought is to have a have common
> repository (https://copr.fedoraproject.org/coprs/g/scitech/common/) for
> updated libraries, then individual repositories for updated programs
> like octave, julia, etc.

Why COPR instead of EPEL?

EPEL is part of Fedora package git tree, all extra stuff from Fedora is 
available in one place...

For me COPR is good solution for tests before package lands in Fedora (or 
EPEL).
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Dead entries in pkgdb?

[Marcin Juszkiewicz]

W dniu 17.12.2015 o 16:11, Michael Schwendt pisze:

http://pkgs.fedoraproject.org/cgit/?q=actdiag
doesn't find the git repo either.

Same for "seqdiag" and "nwdiag".


Review request for "actdiag":
https://bugzilla.redhat.com/show_bug.cgi?id=1072065

Watch this ->

| New Package SCM Request  2014-03-04
| ===
| Package Name: actdiag

| Git done (by process-git-requests).

| I have mistakenly forgotten the "python-" prefix for this
| package (not in the rpm spec though).

| New Package SCM Request  2014-03-07
| ===
| Package Name: python-actdiag

| Git done (by process-git-requests).


Probably similar for nwdiag and seqdiag.
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Dead entries in pkgdb?

[Marcin Juszkiewicz]

Hi

As part of my work as AArch64 secondary architecture developer 
I keep git trees of all Fedora packages on my development machine. 
Tend to update it ~weekly.

Script for it is easy:

#!/bin/bash

HTMP=`mktemp -d`

echo "fetching Fedora packages list"
pkgdb-cli list |cut -d" " -f4 |sort >$HTMP/fedoralist
ls -d1 * |sort >$HTMP/localpackages
diff -u $HTMP/localpackages $HTMP/fedoralist |grep ^+|sed -e "s/^+//g"|grep -v 
fedoralist >$HTMP/newpackages
echo "new packages are:"
cat $HTMP/newpackages
echo "cloning new packages"
for pkg in `cat $HTMP/newpackages`;
do
fedpkg clone $pkg
done


But there are entries in pkgdb which can not be fetched that way:

actdiag
gnome-cpufreq-applet
kf5-textwidgets
nwdiag
python-elementtree
repsurgeon
R-gnomeGUI
seqdiag
tetex-beamer
tetex-pgf
tetex-xcolor

All those packages were orphaned and removed from git. Time to kill 
them from pkgdb as well?
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Proposal: retire lesstif in f24 and beyond

[Marcin Juszkiewicz]

W dniu 08.10.2015 o 12:06, Marcin Juszkiewicz pisze:

W dniu 02.10.2015 o 13:33, Jon Ciesla pisze:

Lesstif being basically dead upstream and motif being available, I think
it's probably time to retire lesstif.



If anyone knows of other packages using it, please let me know and I can
migrate them.


dinotrace
fbb
xastir
xmbdfed
xvarstar

Those are blocking aarch64. Will dig for more.


alliance
polyml

That's all I found.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Proposal: retire lesstif in f24 and beyond

[Marcin Juszkiewicz]

W dniu 02.10.2015 o 13:33, Jon Ciesla pisze:

Lesstif being basically dead upstream and motif being available, I think
it's probably time to retire lesstif.



If anyone knows of other packages using it, please let me know and I can
migrate them.


dinotrace
fbb
xastir
xmbdfed
xvarstar

Those are blocking aarch64. Will dig for more.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Orphaned packages seeking new point of contact

[Marcin Juszkiewicz]

W dniu 08.10.2015 o 01:29, Eduardo Mayorga Téllez pisze:

El 07/10/2015 2:05 pm, Kevin Fenzi escribió:

xcircuit -- Electronic circuit schematic drawing program ( master f23
f22 f21 el6 el5 )


Taken.


Can you also take ngspice? Otherwise one of xcircuit build dependencies 
will be removed from Fedora.


--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: SPF records @fedoraproject.org versus @lists.fedoraproject.org

[Marcin Juszkiewicz]

W dniu 05.10.2015 o 16:58, Reindl Harald pisze:

Am 05.10.2015 um 16:47 schrieb Marcin Juszkiewicz:



Many of those people send their mail from properly configured MTA
allowing random envelope senders for authenticated users


well, and that's why spamfighting is that complicated
a MTA allowing random sender is *not* properly configured


My MTA has to send my emails. I connect, authenticate and provide emails 
to send. I may fetch them from many different servers but send them 
through one SMTP server.



i guess you don't use random sevrers fro your @redhat.com


My emails from company address go through company MTA because that's 
policy and they can contain confidential information.


--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: SPF records @fedoraproject.org versus @lists.fedoraproject.org

[Marcin Juszkiewicz]

W dniu 05.10.2015 o 16:43, Reindl Harald pisze:

well, that people should send their mail from the Fedora servers and
not from a wrong configured random MTA allowing random envelope
senders


Many of those people send their mail from properly configured MTA 
allowing random envelope senders for authenticated users.

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: f23: dnf returns nothing

[Marcin Juszkiewicz]

W dniu 30.09.2015 o 10:39, Pavel Lisý pisze:

For others

I have found discussion in other maillist
For testing and quality assurance of Fedora releases
mailto:for%20testing%20and%20quality%20assurance%20of%20fedora%20releases%20%3ct...@lists.fedoraproject.org%3e>>

It was bug in dnf:

workaround:


"yum-deprecated update dnf" is easier.

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Why packages sources are NOT mirrored?

[Marcin Juszkiewicz]

W dniu 17.09.2015 o 22:42, Kevin Fenzi pisze:

> >I would talk with the mirrors in your area and find out why they
> >don't mirror it.

>
>Do mirror sites have the option to not include sources? [*]



The pkgs.fedoraproject.org lookaside cache?
(Which is what this thread was about)
No, because we don't offer it for mirroring currently.


Ok, for next time when I will have that issue I will forget about 
'fedpkg sources' and will fetch srpm, extract it and then build local 
srpm for hacking package for local build.


It would be nice to have an option/fallback in fedpkg to do it 
automatically but it is not so often needed.

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Why packages sources are NOT mirrored?

[Marcin Juszkiewicz]

My traceroute  [v0.85]
puchatek (0.0.0.0)Thu Sep 17 14:42:22 2015
Keys:  Help   Display mode   Restart statistics   Order of fields quit
 Packets   Pings
 Host   Loss%   Snt   Last   Avg  Best  Wrst StDev
 1. krzys.lan0.0%160.3   0.3   0.3   0.3   0.0
 2. 192.168.0.1  0.0%160.6   0.6   0.5   0.8   0.0
 3. ???
 4. 89-75-11-97.infra.chell  0.0%168.5   9.7   7.3  16.4   2.1
 5. 84.116.252.162   0.0%16  224.2 220.9 218.1 227.2   2.4
 6. 84.116.252.174   0.0%16  219.6 220.3 218.3 226.8   1.9
 7. 84.116.252.9 0.0%15  223.8 221.4 219.9 225.0   1.5
 8. 84.116.252.410.0%15  230.5 221.8 219.6 230.5   2.7
 9. 84.116.136.141  71.4%15   44.0  42.3  40.7  44.0   1.3
10. 84-116-130-130.aorta.ne  0.0%15  222.2 220.3 218.2 227.9   2.3
11. ch-zrh02a-ra1-xe-2-1-0.  0.0%15  224.3 229.6 219.6 251.9  11.2
12. 84-116-130-125.aorta.ne 85.7%15   42.3  41.5  40.8  42.3   1.0
13. 84-116-130-122.aorta.ne  0.0%15  148.2 149.9 145.4 177.0   8.2
14. 84.116.133.158   0.0%15  222.7 220.7 219.5 222.7   0.7
15. mpr1.sjc7.us 0.0%15  222.5 223.3 219.4 253.3   8.5
16. ae9.cr1.sjc2.us.zip.zay  0.0%15  249.4 225.0 218.8 249.4   9.7
17. v11.ae29.cr1.lax112.us.  0.0%15  232.1 231.2 228.1 240.9   3.1
18. ae7.mpr3.phx2.us.zip.za  0.0%15  242.7 239.8 236.5 249.9   3.5
19. 208.184.108.38.IPYX-072  0.0%15  223.8 222.8 221.5 226.2   1.1
20. border1.po1-bbnet1.phx0  0.0%15  221.7 222.2 220.7 226.0   1.3
21. redhat-2.border1.phx004  0.0%15  226.7 224.8 222.0 238.2   3.9
22. tx-160-181-132-209.redh  0.0%15  222.4 222.7 221.4 227.2   1.4
23. pkgs.fedoraproject.org   0.0%15  232.3 225.3 222.6 232.3   2.7

This is my connection to pkgs.fedoraproject.org machine. Fetching 48MB 
archive reached 36% in 2 (two) hours...


We ship binaries through mirrors all around the world. yum/dnf knows how 
to use them to get packages in a quick way. Knows how to handle lack of 
connection etc.


But sources used to build packages came from one place. ONE...

Why? Why we are not have them mirrored?

Or if we have then which magic option I did not managed to find yet?
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: when DEP-3 compliant patches in Fedora?

[Marcin Juszkiewicz]

W dniu 28.08.2015 o 18:02, Matěj Cepl pisze:

On 2015-08-28, 13:01 GMT, Marcin Juszkiewicz wrote:

Yes, I have read it. But lot of maintainers did not.

Example specfile:

Source1:%{name}.score
Patch0: %{name}-0.7.1-userpmopts.patch
Patch1: %{name}-0.7.1-64bitfix.patch
Patch2: %{name}-0.7.1-blit-crash.patch


Well, perhaps instead of non-sensical (meaning, it cannot get to
any meaningful resolution) discussion on devel, I would think
that filing a bug could lead to something?


You mean mass bug reporting for each package where spec file lacks 
information about patches?


Prefer to spend that time on fixing those packages where aarch64 or 
other secondary architecture is not handled.



--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: when DEP-3 compliant patches in Fedora?

[Marcin Juszkiewicz]

W dniu 28.08.2015 o 14:40, Kevin Kofler pisze:

Marcin Juszkiewicz wrote:

In Debian (or in OpenEmbedded) it is solved by implementing DEP-3 [1]
which is set of requirements about extra metadata in patches such as:

- Description or Subject (required)
- Origin (required except if Author is present)
- Bug- or Bug (optional)
- Forwarded (optional)
- Author or From (optional)
- Reviewed-by or Acked-by (optional)
- Last-Update (optional)
- Applied-Upstream (optional)


I am opposed to any such scheme, because it means we could no longer produce
our patches with diff without hand-editing them.


Ever heard of "quilt"? It even has handling of sane spec files built-in.

My common way of tweaking Fedora patches is this:

cd ~/rpmbuild/fedora-packager/PACKAGENAME/
git up
quilt setup -v *spec
cd SOURCENAME-VERSION
quilt push -a

And then I have upstream source with Fedora patches applied. 'quilt 
push/pop' allows me to apply/revert patches, 'quilt refresh' refreshes 
patch (amount of context lines etc can be configured, description is 
kept, diffstat can be added).


Try it one day?
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: when DEP-3 compliant patches in Fedora?

[Marcin Juszkiewicz]

W dniu 28.08.2015 o 14:44, Florian Weimer pisze:

On 08/28/2015 02:11 PM, Marcin Juszkiewicz wrote:



Who knows what it does and why? For some reason it has a name
'64bitfix' but why it is needed? Did upstream ever saw it? No
idea.



In reality, here's what the Debian version of this patch looks like:

<http://sources.debian.net/src/monsterz/0.7.1-8/debian/patches/010_64-bit-alignment-issues-with-python2.5.diff/>

 I'm not sure if it's all that more helpful, to be honest.


I would say that it is a bit better. Now I at least know that it is
related to Python 2.5 (which we no longer ship) and some 64bit alignment
issues due to it ;D


(In general, if there is no upstream to contribute such fixes to,
it's probably best not to ship such software at all.)


But yes, with dead upstream it is not so funny.


--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: when DEP-3 compliant patches in Fedora?

[Marcin Juszkiewicz]

W dniu 28.08.2015 o 14:51, Neal Gompa pisze:


​If patches are exported from Mercurial or Git, y​ou'd have all the
information you'd want.


Fully agree. Only info about upstream status is missing.


However, most people I know aren't working from the hg/git
repository when making packages. That said, I would seriously hope
there would be comments in the spec indicating why the patch is
needed.



I know that when I have to make patches to packages, I will put
comments right above the patch source line with information about the
patch.


Often there is not even such information ;(
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: when DEP-3 compliant patches in Fedora?

[Marcin Juszkiewicz]

W dniu 28.08.2015 o 14:32, Björn Persson pisze:

Marcin Juszkiewicz  wrote:



Have you read the existent policy on this?
http://fedoraproject.org/wiki/Packaging:Guidelines#Patch_Guidelines


Yes, I have read it. But lot of maintainers did not.

Example specfile:

Source1:%{name}.score
Patch0: %{name}-0.7.1-userpmopts.patch
Patch1: %{name}-0.7.1-64bitfix.patch
Patch2: %{name}-0.7.1-blit-crash.patch

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

when DEP-3 compliant patches in Fedora?

[Marcin Juszkiewicz]

Hi

I am building software for misc distributions for over 11 years. And so
far Fedora packages are the worst of those I played with (mostly
OpenEmbedded and Debian).

Why? Because patches are mess. Let's take random one:

@@ -108,7 +108,7 @@
 M = int(max(r, g, b))
 m = int(min(r, g, b))
 val = (2 * M + r + g + b) / 5
-p[:] = (val + r) / 2, (val + g) / 2, (val + b) / 2
+#p[:] = (val + r) / 2, (val + g) / 2, (val + b) / 2
 if alpha[y][x] >= 250:
 alpha[y][x] = 255 - (M - m) * 3 / 4
 del pixels

Who knows what it does and why? For some reason it has a name '64bitfix'
but why it is needed? Did upstream ever saw it? No idea.

In Debian (or in OpenEmbedded) it is solved by implementing DEP-3 [1]
which is set of requirements about extra metadata in patches such as:

- Description or Subject (required)
- Origin (required except if Author is present)
- Bug- or Bug (optional)
- Forwarded (optional)
- Author or From (optional)
- Reviewed-by or Acked-by (optional)
- Last-Update (optional)
- Applied-Upstream (optional)

1. http://dep.debian.net/deps/dep3/

Examples:


A patch cherry-picked from upstream:

From: Ulrich Drepper 
Subject: Fix regex problems with some multi-bytes characters

* posix/bug-regex17.c: Add testcases.
* posix/regcomp.c (re_compile_fastmap_iter): Rewrite COMPLEX_BRACKET
  handling.

Origin: upstream, http://sourceware.org/git/?p=glibc.git;a=commitdiff;h=bdb56bac
Bug: http://sourceware.org/bugzilla/show_bug.cgi?id=9697
Bug-Debian: http://bugs.debian.org/510219

A patch created by the Debian maintainer John Doe, which got forwarded and 
rejected:

Description: Use FHS compliant paths by default
 Upstream is not interested in switching to those paths.
 .
 But we will continue using them in Debian nevertheless to comply with
 our policy.
Forwarded: http://lists.example.com/oct-2006/1234.html
Author: John Doe 
Last-Update: 2006-12-21

A vendor specific patch not meant for upstream submitted on the BTS by a Debian 
developer:

Description: Workaround for broken symbol resolving on mips/mipsel
 The correct fix will be done in etch and it will require toolchain
 fixes.
Forwarded: not-needed
Origin: vendor, http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=80;bug=265678
Bug-Debian: http://bugs.debian.org/265678
Author: Thiemo Seufer 

A patch submitted and applied upstream:

Description: Fix widget frobnication speeds
 Frobnicating widgets too quickly tended to cause explosions.
Forwarded: http://lists.example.com/2010/03/1234.html
Author: John Doe 
Applied-Upstream: 1.2, http://bzr.example.com/frobnicator/trunk/revision/123
Last-Update: 2010-03-29



Are there any plans on adding/enforcing such requirements at least for new
patches? 

Maintainers are not the only persons who work on their packages. Sometimes some
random developers go though random packages for several reasons (fixing ftbfs on
secondary architectures, mass rebuilds etc). There is also "bus factor" which
can wipe maintainer from existence or people just orphan own packages. 

Why we have to check patch after patch for their reason or upstream status?
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Do you know how many 64-bit architectures Fedora has?

[Marcin Juszkiewicz]

W dniu 24.08.2015 o 16:09, Jonathan Underwood pisze:

It would be worthwhile adding this to:

https://fedoraproject.org/wiki/Packaging_tricks


Added
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Do you know how many 64-bit architectures Fedora has?

[Marcin Juszkiewicz]

W dniu 24.08.2015 o 15:31, Neal Gompa pisze:


​ Well, the problem is that ​the path to apt-methods is hardcoded in
reprepro itself. Thankfully, it's in a #define, but I don't know of a
good way to fix it beyond just replacing the #define for 64-bit systems.
​If someone can suggest a better way than how I'm doing it now, I'm all
ears, because I hate this patch[0].


At end of %setup add:

sed -i -e 's+/usr/lib+%{_libdir}+g' main.c

and it will replace /usr/lib with proper value on both 32 and 64 bit.


--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Do you know how many 64-bit architectures Fedora has?

[Marcin Juszkiewicz]

W dniu 24.08.2015 o 15:18, Neal Gompa pisze:

​ Oh, yes! I was trying to find something like this all weekend for my
Copr for reprepro. I have to make a patch to access apt-methods in
/usr/lib64 on 64-bit systems, but on 32-bit systems it should remain
/usr/lib.

You just made my day. ​


You know that %_libdir is what you want? /usr/lib on 32bit, /usr/lib64 
on 64bit.

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Do you know how many 64-bit architectures Fedora has?

[Marcin Juszkiewicz]

Hi

During last few days I fetched over 26 thousand of Fedora package 
repositories. Plan to go though all spec files and submit some patches 
mainly related to my aarch64 work.


We live in a world where most of Linux systems are either 32 or 64 bit. 
But do you know how many 64-bit architectures Fedora and RHEL have?


According to spec files we have at least 8 while current Fedora has 1 
primary and 4 secondary ones.


x86-64 is main one which most of developers use for everything
aarch64 is my favourite secondary one
ppc64 is probably fastest one
ppc64le is little endian version of previous
s390x is fridge size mainframe (is such small exist)

Specs also mention ia64 (not supported Itanium), alpha (I have some 
friends who still own them but do not run), sparc64/sparcv9 (even Debian 
got rid of sparc support).


But why I write?

Because there are lot of code like:

%ifarch x86_64 ppc64 ia64 s390x sparc64
USE_64=1
%endif

Where is should be:

%if 0%{?__isa_bits} == 64
 USE_64=1
%endif

Which works since RHEL6 (from what I know). And it automatically covers 
all 64-bit architectures not only those which maintainer remembers.


So please do me a favour and take a look at your packages and adapt 
their spec files. Otherwise sooner or later such patch may land in 
bugtracker but instead I could fix some other package at same time.

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Valgrind availability

[Marcin Juszkiewicz]

Hi

During last few days I fetched over 26 thousand of Fedora package 
repositories. Plan to go though all spec files and submit some patches 
mainly related to my aarch64 work.


But there is one thing I want to note:

%ifarch %{ix86} x86_64
BuildRequires: valgrind
%endif

Currently there is only one architecture in Fedora which does not have 
Valgrind support and it is s390 (32-bit s/390). x86(-64) has it, arm32 
and aarch64 have them, ppc64(le) has it too.


So if your package build depends on Valgrind (or valgrind-devel) please 
consider change to:


%ifnarch s390
BuildRequires: valgrind
%endif

I know that some maintainers do not like to look at their packages on 
architectures other than x86(-64) because they do not own hardware, do 
not like being hit by bugs in valgrind or have other excuses. If you are 
one of them then please add a note to spec file about. Check "cscppc" 
package for example.


Sure, some packages may fail due to bug in valgrind implementation on 
some secondary architecture. But then we can notify developers so it 
will get improved (while in same time package may get this build 
dependency disabled for a while).

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: DNF 1.0.2 Released

[Marcin Juszkiewicz]

W dniu 22.07.2015 o 10:49, Honza Šilhan pisze:

> The resolution configuration hints are printed to the output and user
> is notified which packages were skipped during update in case there
> are conflicts.

No information about skipped updates on my system (or I misunderstood
how it is supposed to work):

# dnf update --best
Last metadata expiration check performed 0:03:19 ago on Tue Jul 28 08:41:56 
2015.
Error: package libreoffice-pdfimport-1:5.0.0.3-1.fc23.x86_64 requires 
libpoppler.so.52()(64bit), but none of the providers can be installed.
package libreoffice-pdfimport-1:5.0.0.3-1.fc23.x86_64 requires 
libpoppler.so.52()(64bit), but none of the providers can be installed.
package libreoffice-pdfimport-1:5.0.0.3-1.fc23.x86_64 requires 
libpoppler.so.52()(64bit), but none of the providers can be installed.
package libreoffice-pdfimport-1:5.0.0.3-1.fc23.x86_64 requires 
libpoppler.so.52()(64bit), but none of the providers can be installed.
package libreoffice-pdfimport-1:5.0.0.3-1.fc23.x86_64 requires 
libpoppler.so.52()(64bit), but none of the providers can be installed.
package libreoffice-pdfimport-1:5.0.0.3-1.fc23.x86_64 requires 
libpoppler.so.52()(64bit), but none of the providers can be installed

# dnf update

Transaction Summary
==
Install 15 Packages
Upgrade 479 Packages
Remove 5 Packages

Total download size: 591 M

# dnf --version
1.0.2
  Installed: dnf-0:1.0.2-2.fc24.noarch at 2015-07-28 06:41
  Built: Fedora Project at 2015-07-21 16:35

  Installed: rpm-0:4.12.0.1-17.fc23.x86_64 at 2015-07-14 11:25
  Built: Fedora Project at 2015-06-29 10:26
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct