Re: Issue with an update, need advice Re: [Fedora Update] [comment] papirus-icon-theme-20190302-1.fc30

[Panu Matilainen]

On 3/12/19 6:07 AM, Robert-André Mauchin wrote:

Hello,

I have an issue with the update of papirus-icon-theme: in the new version, 
symlinks
have replaced what was previously folders and dnf errors out on this:

For example, on the current version:

$ ll /usr/share/icons/Papirus-Light/16x16

total 24K
drwxr-xr-x. 1 root root  73K nov.   6 16:36 actions/
lrwxrwxrwx. 1 root root   24 oct.  22 16:33 apps -> ../../Papirus/16x16/apps/
lrwxrwxrwx. 1 root root   30 oct.  22 16:33 categories -> 
../../Papirus/16x16/categories/
drwxr-xr-x. 1 root root 6,9K nov.   6 16:36 devices/
lrwxrwxrwx. 1 root root   27 oct.  22 16:33 emblems -> 
../../Papirus/16x16/emblems/
lrwxrwxrwx. 1 root root   27 oct.  22 16:33 emotes -> 
../../Papirus/16x16/emotes//
lrwxrwxrwx. 1 root root   29 oct.  22 16:33 mimetypes -> 
../../Papirus/16x16/mimetypes/
drwxr-xr-x. 1 root root  59K nov.   6 16:36 panel/
drwxr-xr-x. 1 root root 4,5K nov.   6 16:36 places/
lrwxrwxrwx. 1 root root   26 oct.  22 16:33 status -> 
../../Papirus/16x16/status/

On the new version:

$ ll /usr/share/icons/Papirus-Light/16x16

total 36K
lrwxrwxrwx. 1 root root  27 mars  11 16:16 actions -> 
../../Papirus/16x16/actions/
lrwxrwxrwx. 1 root root  24 mars  11 16:16 apps -> ../../Papirus/16x16/apps/
lrwxrwxrwx. 1 root root   4 mars  11 16:16 categories -> apps/
lrwxrwxrwx. 1 root root  27 mars  11 16:16 devices -> 
../../Papirus/16x16/devices/
lrwxrwxrwx. 1 root root  27 mars  11 16:16 emblems -> 
../../Papirus/16x16/emblems/
lrwxrwxrwx. 1 root root  26 mars  11 16:16 emotes -> ../../Papirus/16x16/emotes/
lrwxrwxrwx. 1 root root  29 mars  11 16:16 mimetypes -> 
../../Papirus/16x16/mimetypes/
drwxr-xr-x. 1 root root 60K mars  12 04:52 panel/
lrwxrwxrwx. 1 root root  26 mars  11 16:16 places -> ../../Papirus/16x16/places/
lrwxrwxrwx. 1 root root  26 mars  11 16:16 status -> ../../Papirus/16x16/status/


Why doesn't dnf simply remove the previous folders and replace them with 
symlinks?


Because if you think about it from the point of something like glibc, 
the new version has to be installed before the old one can be removed. 
And now if you think about that, and what would happen if the directory 
in question was something like /bin instead of a rarely visited dark 
corner in /usr/share (but nah, who would ever do such a thing...)


> How can I solve this?
>

https://fedoraproject.org/wiki/Packaging:Directory_Replacement

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

Fedora 30-20190312.n.0 compose check report

[Fedora compose checker]

Missing expected images:

Atomichost raw-xz x86_64
Atomichost qcow2 x86_64

Failed openQA tests: 10/141 (x86_64), 1/2 (arm)

ID: 362235  Test: x86_64 Workstation-live-iso desktop_update_graphical
URL: https://openqa.fedoraproject.org/tests/362235
ID: 362239  Test: x86_64 Workstation-live-iso apps_startstop
URL: https://openqa.fedoraproject.org/tests/362239
ID: 362247  Test: x86_64 Workstation-boot-iso memory_check
URL: https://openqa.fedoraproject.org/tests/362247
ID: 362248  Test: x86_64 Workstation-boot-iso memory_check@uefi
URL: https://openqa.fedoraproject.org/tests/362248
ID: 362265  Test: x86_64 KDE-live-iso desktop_browser
URL: https://openqa.fedoraproject.org/tests/362265
ID: 362267  Test: arm Minimal-raw_xz-raw.xz 
install_arm_image_deployment_upload
URL: https://openqa.fedoraproject.org/tests/362267
ID: 362314  Test: x86_64 universal install_european_language
URL: https://openqa.fedoraproject.org/tests/362314
ID: 362332  Test: x86_64 universal install_cyrillic_language
URL: https://openqa.fedoraproject.org/tests/362332
ID: 362333  Test: x86_64 universal install_arabic_language
URL: https://openqa.fedoraproject.org/tests/362333
ID: 362346  Test: x86_64 universal install_asian_language
URL: https://openqa.fedoraproject.org/tests/362346
ID: 362347  Test: x86_64 universal install_iscsi
URL: https://openqa.fedoraproject.org/tests/362347

Soft failed openQA tests: 12/141 (x86_64), 5/24 (i386)
(Tests completed, but using a workaround for a known bug)

ID: 362201  Test: x86_64 Server-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/362201
ID: 362202  Test: x86_64 Server-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/362202
ID: 362203  Test: x86_64 Server-dvd-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/362203
ID: 362204  Test: x86_64 Server-dvd-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/362204
ID: 362220  Test: x86_64 Server-dvd-iso server_realmd_join_kickstart
URL: https://openqa.fedoraproject.org/tests/362220
ID: 362228  Test: i386 Server-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/362228
ID: 362229  Test: i386 Server-dvd-iso install_default
URL: https://openqa.fedoraproject.org/tests/362229
ID: 362251  Test: i386 Workstation-boot-iso memory_check
URL: https://openqa.fedoraproject.org/tests/362251
ID: 362309  Test: x86_64 universal upgrade_server_64bit
URL: https://openqa.fedoraproject.org/tests/362309
ID: 362310  Test: x86_64 universal upgrade_server_domain_controller
URL: https://openqa.fedoraproject.org/tests/362310
ID: 362318  Test: x86_64 universal install_anaconda_text
URL: https://openqa.fedoraproject.org/tests/362318
ID: 362338  Test: x86_64 universal upgrade_desktop_64bit
URL: https://openqa.fedoraproject.org/tests/362338
ID: 362339  Test: x86_64 universal upgrade_realmd_client
URL: https://openqa.fedoraproject.org/tests/362339
ID: 362341  Test: x86_64 universal upgrade_desktop_encrypted_64bit
URL: https://openqa.fedoraproject.org/tests/362341
ID: 362344  Test: x86_64 universal upgrade_2_server_64bit
URL: https://openqa.fedoraproject.org/tests/362344
ID: 362365  Test: i386 universal upgrade_desktop_32bit
URL: https://openqa.fedoraproject.org/tests/362365
ID: 362366  Test: i386 universal upgrade_2_desktop_32bit
URL: https://openqa.fedoraproject.org/tests/362366

Passed openQA tests: 119/141 (x86_64), 19/24 (i386)

Skipped non-gating openQA tests: 1 of 167
-- 
Mail generated by check-compose:
https://pagure.io/fedora-qa/check-compose
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://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: Blocking criteria proposal for F30+: Printing

[Zdenek Dohnal]

On 3/11/19 10:52 PM, Chris Murphy wrote:
> On Thu, Feb 28, 2019 at 2:56 PM Stephen Gallagher  wrote:
>
>> * Printing must work on at least one printer available to Fedora QA.
>> "Work" is defined as the output from the device matching a preview
>> shown on the GNOME print preview display. (Note that non-ridiculous
>> differences in color reproduction are not considered "non-working". In
>> general, we'll apply the "last blocker at Go/No-Go" principle here
>> when deciding whether a print glitch is truly blocking.)
>>
>> and this to Final for Fedora 30+:
>> * Printing must work (as defined above) on at least one printer using
>> each of the following drivers:
>> - The built-in print-to-PDF driver
>> - The generic IPP driver
>> * For each blocking desktop, it must be possible to print:
>> - A test page from the desktop environment's built-in "test page"
>> feature, if such a feature exists.
>> - A simple text document of at least 100 words (lorem ipsum) from
>> the standard basic text editor accompanying that desktop.
>>
>> This does not mean that all printers need to function properly that
>> use the IPP driver, just that at least one does (so we
>> know that printing as a whole is unbroken). We won't specify any
>> particular hardware makes or models that must work.
> I think "generic IPP driver" needs to be more specifically stated.
>
> There's IPP protocol versions 1.1, 2.0, 2.1 and 2.2. The "driverless"
> specification is IPP Everywhere, which uses IPP protocol versions 2.0
> or higher, along with additional requirements to support driverless
> device discovery and printing of text and images. There isn't strictly
> speaking a generic IPP driver, although PCL and PostScript are common.
IMHO Stephen meant it as driverless 'driver' or IPP everywhere enabled
printer, since 'generic IPP driver' does not exist.
>
> What supports IPP Everywhere out of the box?
>
> Any computer running CUPS 1.5 or later
I beg to differ that it is not entirely correct. Yes, there are some
features for driverless support in <2.1.0 (approximately), but since it
was not so widely used at that time, some features were still missing or
needed some more tweaks for make it right.
> Mobile devices running Android 4.4 and later
>
> Proposal for Fedora 30: If anyone is able to, with reasonable effort,
> successfully run the agreed test cases to any printer supporting IPP
> 2.0 or higher, using whatever driver is required, then we don't block.

I would go with 'if printing works on IPP everywhere printer available
for Fedora QA' (hooray, we have one :) ) 'then do not block'. But it
seems as technicality...

IMHO blocking the release if 'whatever' IPP everywhere printer does not
work seems like a trap to me - you basically believe that every printer
vendor implemented their IPP server and used HTTP server (IPP is
transfered by HTTP protocol) into printers firmware correctly - which is
not true till now.

> Proposal for Fedora 31: If anyone is able to, with reasonable effort,
> successfully run the agreed test cases to any IPP Everywhere printer,
> then we don't block.
>
> Something I need to dig into deeper is how to create a virtual IPP
> Everywhere printer (a service); which would be useful for testing, in
> particular automated testing such that the virtual printer itself says
> "yes this is a valid print job".
ippsample project does that, you can find it in that github link you
posted, together with sample of ippserver, which should become 'server
solution' for CUPS (the idea is to use CUPS only as client app, and any
infrastructure servers will run only IPP server, which will present
printers to other machines).
>  But also it might be possible to
> bridge the virtual IPP Everywhere printer with a conventional
> CUPS+gimp/foomatic driver based printer.

This idea is similar to which Mike Sweet presented on PWG meetup last
year - printer applications - combination of IPP server(not
CUPS)+specific printer driver provider. I created a report from that PWG
meetup, please see that.

I plan to add all these projects into Fedora to have fully IPP
everywhere solution (ippusbx, ipp-selfcert, ippsample), but not so much
time to do it yet...

>  If so, I'm thinking Fedora
> IoT on a Raspberry Pi Zero W, using a static containerized approach,
> that once working, should be a reliable indicator that any failures
> coinciding with print pipeline changes in the client, are in fact
> client bugs. But we'll see about that.
>
> This might be useful:
> IPP Everywhere mini-tutorial
> https://github.com/apple/cups/wiki/IPP-(Everywhere)-Mini-Tutorial
>
> Other references:
> IPP Everywhere FAQ:
> https://www.pwg.org/ipp/evefaq.html
>
> IPP Everywhere self-certified printers list:
> https://www.pwg.org/dynamo/eveprinters.php
>
-- 
Zdenek Dohnal
Software Engineer
Red Hat Czech - Brno TPB-C

PWG plenary
===

- more meet-ups in aug, november
- pwg membership - redhat doesn't have
- PWG group - chair Smith Kennedy, vice chair Alan Sukert

Re: Allowing Epoch to be reset between releases

[Vít Ondruch]

Dne 11. 03. 19 v 20:50 Jason L Tibbitts III napsal(a):
>> "VO" == Vít Ondruch  writes:
> VO> In this case, if DNF said something like "you have installed
> VO> foo-1:1.0, but there is available foo-0:2.0" it would give me
> VO> hint. From the start it would be annoying, but once we would reach
> VO> the point 4, I would, at least, know that I should do distrosync or
> VO> something.
>
> Under the proposal I put forward:
>
> 1. No releases except for rawhide would ever be affected by this,
>assuming that users upgrade using supported methods.
>
> 2. Rawhide users would need to do this exactly once per cycle, on an
>announced date.


So maintainers would not be allowed to remove epoch, but there would be
some script/automation, which would remove epoch on demand, once per
release, in all packages? Interesting idea.

Anyway, I still believe DNF could report when there is package 0:2.0,
while there is also 1:1.0, because this change, if accepted, is going to
redefine the meaning of epoch anyway. Epoch would basically become some
temporary override no matter what is the precise process.


Vít


>
> So you would know that you should do distrosync because that would be
> announced.
>
>  - J<
___
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

Fedora 30 compose report: 20190312.n.0 changes

[Fedora Branched Report]

OLD: Fedora-30-20190301.n.0
NEW: Fedora-30-20190312.n.0

= SUMMARY =
Added images:12
Dropped images:  4
Added packages:  22
Dropped packages:19
Upgraded packages:   241
Downgraded packages: 2

Size of added packages:  310.08 MiB
Size of dropped packages:228.89 MiB
Size of upgraded packages:   13.28 GiB
Size of downgraded packages: 19.72 MiB

Size change of upgraded packages:   128.74 MiB
Size change of downgraded packages: 1.20 MiB

= ADDED IMAGES =
Image: Cloud_Base vmdk x86_64
Path: Cloud/x86_64/images/Fedora-Cloud-Base-30-20190312.n.0.x86_64.vmdk
Image: Python_Classroom vagrant-libvirt i386
Path: 
Labs/i386/images/Fedora-Python-Classroom-Vagrant-30-20190312.n.0.i386.vagrant-libvirt.box
Image: Python_Classroom vagrant-libvirt x86_64
Path: 
Labs/x86_64/images/Fedora-Python-Classroom-Vagrant-30-20190312.n.0.x86_64.vagrant-libvirt.box
Image: Astronomy_KDE live x86_64
Path: Labs/x86_64/iso/Fedora-Astronomy_KDE-Live-x86_64-30-20190312.n.0.iso
Image: Astronomy_KDE live i386
Path: Labs/i386/iso/Fedora-Astronomy_KDE-Live-i386-30-20190312.n.0.iso
Image: Cloud_Base vmdk aarch64
Path: Cloud/aarch64/images/Fedora-Cloud-Base-30-20190312.n.0.aarch64.vmdk
Image: Container_Base docker aarch64
Path: 
Container/aarch64/images/Fedora-Container-Base-30-20190312.n.0.aarch64.tar.xz
Image: Python_Classroom vagrant-virtualbox i386
Path: 
Labs/i386/images/Fedora-Python-Classroom-Vagrant-30-20190312.n.0.i386.vagrant-virtualbox.box
Image: Python_Classroom vagrant-virtualbox x86_64
Path: 
Labs/x86_64/images/Fedora-Python-Classroom-Vagrant-30-20190312.n.0.x86_64.vagrant-virtualbox.box
Image: Server dvd ppc64le
Path: Server/ppc64le/iso/Fedora-Server-dvd-ppc64le-30-20190312.n.0.iso
Image: Python_Classroom raw-xz armhfp
Path: 
Labs/armhfp/images/Fedora-Python-Classroom-armhfp-30-20190312.n.0-sda.raw.xz
Image: Container_Minimal_Base docker armhfp
Path: 
Container/armhfp/images/Fedora-Container-Minimal-Base-30-20190312.n.0.armhfp.tar.xz

= DROPPED IMAGES =
Image: Server raw-xz armhfp
Path: Server/armhfp/images/Fedora-Server-armhfp-30-20190301.n.0-sda.raw.xz
Image: Minimal raw-xz aarch64
Path: Spins/aarch64/images/Fedora-Minimal-30-20190301.n.0.aarch64.raw.xz
Image: Server raw-xz aarch64
Path: Server/aarch64/images/Fedora-Server-30-20190301.n.0.aarch64.raw.xz
Image: Mate raw-xz armhfp
Path: Spins/armhfp/images/Fedora-Mate-armhfp-30-20190301.n.0-sda.raw.xz

= ADDED PACKAGES =
Package: FAudio-19.03-1.fc30
Summary: FNA is a reimplementation of the Microsoft XNA Game Studio 4.0 Refresh 
libraries
RPMs:libFAudio libFAudio-devel
Size:665.29 KiB

Package: deepin-screensaver-0.0.7-1.fc30
Summary: Screensaver Tool
RPMs:deepin-screensaver deepin-screensaver-data
Size:916.96 KiB

Package: f30-backgrounds-30.0.0-1.fc30
Summary: Fedora 30 default desktop background
RPMs:f30-backgrounds f30-backgrounds-base f30-backgrounds-extras-base 
f30-backgrounds-extras-gnome f30-backgrounds-extras-kde 
f30-backgrounds-extras-mate f30-backgrounds-extras-xfce f30-backgrounds-gnome 
f30-backgrounds-kde f30-backgrounds-mate f30-backgrounds-xfce
Size:121.21 MiB

Package: gap-pkg-crypting-0.9-1.fc30
Summary: Hashes and Crypto in GAP
RPMs:gap-pkg-crypting gap-pkg-crypting-doc
Size:259.84 KiB

Package: gap-pkg-json-2.0.0-1.fc30
Summary: JSON reading and writing for GAP
RPMs:gap-pkg-json gap-pkg-json-doc
Size:407.81 KiB

Package: gap-pkg-uuid-0.6-1.fc30
Summary: RFC 4122 UUIDs for GAP
RPMs:gap-pkg-uuid gap-pkg-uuid-doc
Size:131.18 KiB

Package: gap-pkg-zeromqinterface-0.11-1.fc30
Summary: ZeroMQ bindings for GAP
RPMs:gap-pkg-zeromqinterface gap-pkg-zeromqinterface-doc
Size:416.70 KiB

Package: golang-github-alecthomas-kong-0.1.15-1.fc30
Summary: Kong is a command-line parser for Go
RPMs:golang-github-alecthomas-kong-devel
Size:47.42 KiB

Package: golang-github-bep-tocss-0.6.0-1.fc30
Summary: A simple to use Go API for LibSass
RPMs:golang-github-bep-tocss-devel
Size:13.71 KiB

Package: golang-github-spf13-jwalterweatherman-1.1.0-1.fc30
Summary: Seamless printing to the terminal and logging to a file
RPMs:golang-github-spf13-jwalterweatherman-devel
Size:16.73 KiB

Package: mingw-osinfo-db-tools-1.4.0-1.fc30
Summary: MinGW Windows port of a library for managing OS information for 
virtualization
RPMs:mingw32-osinfo-db-tools mingw64-osinfo-db-tools
Size:169.43 KiB

Package: mozilla-iot-gateway-addon-node-0.4.0-1.fc30
Summary: Node bindings for Mozilla IoT Gateway
RPMs:mozilla-iot-gateway-addon-node
Size:283.20 KiB

Package: ntfs-3g-system-compression-1.0-1.fc30
Summary: NTFS-3G plugin for reading "system compressed" files
RPMs:ntfs-3g-system-compression
Size:156.02 KiB

Package: php-mkopinsky-zxcvbn-php-4.4.2-1.fc30
Summary: Realistic password strength estimation PHP library
RPMs:php-mkopinsky-zxcvbn-php
Size:439.09 KiB

Package: proj-datumgrid-europe-1.1-1.fc30
Summary: European datum shift grid

Re: Updating Rawhide vs GPG keys

[Oron Peled]

Hi,

I suspect it's a chicken and egg issue:
 * Look at /etc/yum.repos.d/fedora-rawhide.repo
 * You can see the line:
   
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-$releasever-$basearch
 * But "$releasever" is determined by the version of "fedora-release" package.
 * So dnf, tries to (re)import f30 gpg key.
 * The import is OK, but doesn't help, because packages are signed with f31 key.

I cannot test it now, since I already did the "manual upgrade" workaround 
yesterday.
Anyone that want to check it:
 * Temporarily edit "gpgkey" and modify "$releasever" to "31"
 * Use dnf to upgrade and check if it imports the new GPG key and work 
correctly.

Bye,

-- 
Oron Peled Voice: +972-4-8228492

"If you take a class in large-scale robotics, can you end up in a
situation where the homework eats your dog?"
 -- Jean-Baptiste Queru

On Monday, 11 March 2019 15:05:17 IST Steven A. Falco wrote:
> On 3/11/19 7:31 AM, Vít Ondruch wrote:
> > Hi,
> > 
> > Can somebody please enlighten me, how to update Rawhide after branching
> > and not using --nogpgcheck?
> > 
> > It seems that Rawhide keys were added in fedora-repos-30-0.4. So this is
> > the package which is still "rawhide" package and has "f31" keys. But
> > this package was not probably signed, because this directory is empty:
> > 
> > https://kojipkgs.fedoraproject.org/packages/fedora-repos/30/0.4/data/signed/
> > 
> > Installing anything from Rawhide fails, because of missing GPG keys.
> > 
> > So is there a way to get the GPG keys via DNF? Would it be possible to
> > sign fedora-repos and fedora-release packages by older key to allow
> > smooth updates?
>  
> I was able to update by first manually updating the keys via:
> 
> cd /var/cache/dnf/rawhide-2d95c80a1fa0a67d/packages
> rpm -Uvh \
> fedora-gpg-keys-31-0.1.noarch.rpm \
> fedora-release-31-0.1.noarch.rpm \
> fedora-release-common-31-0.1.noarch.rpm \
> fedora-repos-31-0.1.noarch.rpm \
> fedora-repos-rawhide-31-0.1.noarch.rpm
> 
> Then I was able to do a normal "dnf update --refresh".
> 
> Note that your package directory location may be slightly different.  I don't 
> know if the "rawhide-2d95c80a1fa0a67d" part is consistent or just where mine 
> happened to be.  But if you search for one of the "keys" packages inside the 
> dnf cache area you should be able to find it.
> 
>   Steve
> ___
> 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


___
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: Allowing Epoch to be reset between releases

[Zbigniew Jędrzejewski-Szmek]

On Mon, Mar 11, 2019 at 02:50:44PM -0500, Jason L Tibbitts III wrote:
> > "VO" == Vít Ondruch  writes:
> 
> VO> In this case, if DNF said something like "you have installed
> VO> foo-1:1.0, but there is available foo-0:2.0" it would give me
> VO> hint. From the start it would be annoying, but once we would reach
> VO> the point 4, I would, at least, know that I should do distrosync or
> VO> something.
> 
> Under the proposal I put forward:
> 
> 1. No releases except for rawhide would ever be affected by this,
>assuming that users upgrade using supported methods.
> 
> 2. Rawhide users would need to do this exactly once per cycle, on an
>announced date.
> 
> So you would know that you should do distrosync because that would be
> announced.

This doesn't sound convincing at all. We *know* that people miss
announcements all the time. Dropping epochs would introduce yet
another case where a "magical" step is needed at a specific time.

We need to remember that dropping epochs also impacts any package
which uses Requires/BuildRequires/Recommends/Conflicts/Obsoletes
on the package dropping the epoch.

Elsewhere in the thread people raised:
- koji-shadow
- external build systems
- third party repos
- custom packages

All those will require periodic rebuilds. The problem is that
those things don't necessarily follow the cadence of Fedora releases.
The proposal to drop epochs sounds like a step that is problematic
and causes extra work now and ongoing for third-party packagers.
And the problem that it solves is niche. The cost of the solution
doesn't seem justified.

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

Bugzilla has (very) outdated information on package maintainers

[Miro Hrončok]

Hi,

I'm doing nonresponsive maintainer (Chris Lalancette) in

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

Yet src.fp.o says the package belongs to Ian McLeod.

This is not the first time I've noticed that the bugzilla info is quite wrong, 
most likely very outdated.


Is this a know issue? Where do I report it if not?

--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://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: Bugzilla has (very) outdated information on package maintainers

[Miro Hrončok]

On 12. 03. 19 11:05, Miro Hrončok wrote:

Hi,

I'm doing nonresponsive maintainer (Chris Lalancette) in

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

Yet src.fp.o says the package belongs to Ian McLeod.

This is not the first time I've noticed that the bugzilla info is quite wrong, 
most likely very outdated.


Is this a know issue? Where do I report it if not?


Ignore me, I've mixed 2 packages together.

--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://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

Non-responsive maintainer Chris Lalancette (clalance)

[Miro Hrončok]

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

Anyone knows how to contact the maintainer?

--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://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: Non-responsive maintainer Chris Lalancette (clalance)

[Daniel P . Berrangé]

On Tue, Mar 12, 2019 at 11:11:01AM +0100, Miro Hrončok wrote:
> https://bugzilla.redhat.com/show_bug.cgi?id=1659737
> 
> Anyone knows how to contact the maintainer?

According to git history Chris hasn't touched that package in dist-git
since the very first import in 2011, so is likely the wrong person to
be contacting, and indeed probably shouldn't be listed as maintainer
anymore either.

The only people to update its content are Dennis Gilmore or Ian McLeod.
If neither of them wants to be the official primary maintainer, then it
looks like a candidate for dropping from from the distro.

Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
___
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: Non-responsive maintainer Chris Lalancette (clalance)

[Peter Robinson]

On Tue, Mar 12, 2019 at 10:12 AM Miro Hrončok  wrote:
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1659737
>
> Anyone knows how to contact the maintainer?

He is occasionally active, he still has an active github account, you
can probably get hold of him via contact details there.

imagefactory, and oz, is used by koji for image builds for
arm/cloud/containers so it's still actively used in Fedora infra.

Peter
___
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: Issue with an update, need advice Re: [Fedora Update] [comment] papirus-icon-theme-20190302-1.fc30

[Florian Weimer]

* Panu Matilainen:

> Because if you think about it from the point of something like glibc,
> the new version has to be installed before the old one can be
> removed. And now if you think about that, and what would happen if the
> directory in question was something like /bin instead of a rarely
> visited dark corner in /usr/share (but nah, who would ever do such a
> thing...)

But that's only relevant if the directory contains packaged files which
belong to other packages, right?

Thanks,
Florian
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://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

Orphaned packages to be retired (Java packages in 3 weeks)

[Miro Hrončok]

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

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

Grep the list for your FAS name, follow the transitive deps:
https://churchyard.fedorapeople.org/orphans-2019-03-11.txt

Request package ownership via releng ticket: https://pagure.io/releng/issues

Package  (co)maintainers   Status Change

OSGi-bundle-ant-task  orphan   5 weeks ago
SimplyHTMLmizdebsk, orphan 4 weeks ago
aether-connector-okhttp   galileo, mizdebsk, orphan4 weeks ago
ant-contrib   davidcl, mizdebsk, orphan4 weeks ago
antlr3dchen, lef, mizdebsk,4 weeks ago
  mjakubicek, orphan, walters
aopalliance   mizdebsk, orphan 4 weeks ago
apache-commons-beanutils  fnasser, mizdebsk, orphan,   4 weeks ago
  spike
apache-commons-collectionsjcapik, mizdebsk, orphan 4 weeks ago
apache-commons-collections4   mizdebsk, orphan 4 weeks ago
apache-commons-compress   mizdebsk, mkoncek, orphan,   4 weeks ago
  spike
apache-commons-configuration  fnasser, mizdebsk, orphan,   4 weeks ago
  spike
apache-commons-csvlef, mizdebsk, orphan, spike 4 weeks ago
apache-commons-discovery  lkundrak, mizdebsk, orphan,  4 weeks ago
  spike
apache-commons-el fnasser, mizdebsk, orphan,   4 weeks ago
  spike
apache-commons-fileupload jerboaa, mizdebsk, mmraka,   4 weeks ago
  orphan, spike
apache-commons-jexl   mizdebsk, orphan 4 weeks ago
apache-commons-jxpath fnasser, mizdebsk, orphan,   4 weeks ago
  spike
apache-commons-netmizdebsk, orphan, spike  4 weeks ago
apache-ivymizdebsk, orphan 4 weeks ago
apache-james-project  lef, mizdebsk, orphan4 weeks ago
apache-logging-parent mizdebsk, orphan 4 weeks ago
apache-mime4j lef, mizdebsk, orphan4 weeks ago
apache-parent mizdebsk, orphan 4 weeks ago
apache-ratmizdebsk, orphan 4 weeks ago
apache-resource-bundles   mizdebsk, orphan 4 weeks ago
apiguardian   mizdebsk, orphan 4 weeks ago
aqute-bnd jcapik, mizdebsk, orphan 4 weeks ago
args4jjcapik, mizdebsk, orphan 4 weeks ago
atinject  kdaniel, mizdebsk, orphan4 weeks ago
avalon-framework  jerboaa, mizdebsk, orphan4 weeks ago
avalon-logkit jerboaa, mizdebsk, orphan4 weeks ago
base64coder   jcapik, mizdebsk, orphan 4 weeks ago
batik jvanek, mizdebsk, orphan 4 weeks ago
bcel  mizdebsk, orphan 4 weeks ago
bea-stax  jcapik, mizdebsk, orphan 4 weeks ago
beust-jcommander  jcapik, jvanek, mizdebsk,4 weeks ago
  orphan
blobbyorphan   5 weeks ago
bsf   choeger, mizdebsk, orphan4 weeks ago
bsh   mizdebsk, orphan 4 weeks ago
c3p0  dchen, lef, orphan   4 weeks ago
cal10nmizdebsk, orphan 4 weeks ago
catkinorphan, rmattes, robotics-sig,   7 weeks ago
  thofmann
checkstyledbhole, greghellings, lef,   4 weeks ago
  mizdebsk, nsantos, orphan,
  rmyers
clang5.0  orphan, tstellar 5 weeks ago
clang6.0  orph

Re: Orphaned packages to be retired (Java packages in 3 weeks)

[Jakub Jelen]

Is there already a way to package the java application as a module or
we will really remove all these package from Fedora?

I am really not interested in maintaining a whole java frameworks
stack, but some guidance (not these weekly emails) from java
maintainers team that took this decision would be appreciated.

Regards,
Jakub

On Tue, 2019-03-12 at 11:38 +0100, Miro Hrončok wrote:
> The following packages are orphaned and will be retired when they
> are orphaned for six weeks, unless someone adopts them. If you know
> for sure
> that the package should be retired, please do so now with a proper
> reason:
> https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life
> 
> Note: If you received this mail directly you (co)maintain one of the
> affected
> packages or a package that depends on one. Please adopt the affected
> package or
> retire your depending package to avoid broken dependencies, otherwise
> your
> package will be retired when the affected package gets retired.
> 
> Grep the list for your FAS name, follow the transitive deps:
> https://churchyard.fedorapeople.org/orphans-2019-03-11.txt
> 
> Request package ownership via releng ticket: 
> https://pagure.io/releng/issues

...
___
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: Orphaned packages to be retired (Java packages in 3 weeks)

[Miro Hrončok]

On 12. 03. 19 11:48, Jakub Jelen wrote:

Is there already a way to package the java application as a module or
we will really remove all these package from Fedora?


You can build Java apps as modules, yes.
If we remove the mentioned packages from rawhide, it will be the only way to 
build Java packages.
No, there is not yet supported way to build "normal" packages with modular 
buildrequires.
Yes, I'm really going to retire those packages on rawhide if nobody picks them 
or if we don't agree on an exception (such as, wait X extra weeks before the 
problem is solved).



I am really not interested in maintaining a whole java frameworks
stack, but some guidance (not these weekly emails) from java
maintainers team that took this decision would be appreciated.


I'd appreciate it as well.

--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://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: Downgrading glibc from Rawhide removed /bin/sh (!)

[Panu Matilainen]

On 3/11/19 12:29 PM, Florian Weimer wrote:

* Panu Matilainen:


It's glibc's own %post own scripts that are somehow breaking it. I've
a minimal reproducer here with glibc 2.29 in /srv/root chroot. The
bash version is just to show whether bash is alive or not:


Yes, you are right, I had actually looked at this failure a few weeks
ago and reached similar conclusions (my memory is failing).


glibc's %post is /usr/sbin/glibc_post_upgrade., so that's what's
doing something bad here. When straced through forks and all, guess
what? It's running ldconfig:


Right, we have to do that unfortunately.

So the problem is not the symbolic link handling, but the fact that the
scriptlets run while old files still stick around, before RPM deletes
them closer to the end of the transaction.  And *this* happens because
we use symbolic links to the actual implementation.  If we didn't do
that, RPM would have no choice and would have to replace the files on
disk, so that the old version is gone.

We actually have compensating code in glibc_post_upgrade for these
lingering files, deleting files early that would break scriptlets which
run before they are deleted by RPM.

The question is whether we want to extend this code to cover more cases.
This is quite hard to do however, especially for downgrades, because we
do not know which files to delete in the %post scriptlet of the old
version (which cannot foretell the changes the newer glibc version that
is being removed brought in).  Presumably, we could look at the file
list in the RPM database and delete anything that's not part of the
current package version (the one whose %post is running).

I had already raised the issue with the symbolic links upstream (as I
said, my memory is failing), and feedback was not exactly positive:

   

In fact, Siddhesh suggested using *more* symbolic links:

   

What's RPM's justification for deleting files so late in the
transaction?  Can this be changed at the RPM level?  I'm sure we aren't
the only ones affected by this.


The answer is basically twofold:

1) Rpm cannot do removals as long as there are dependencies on the older 
versions, eg on library soname changes an early erasure could cause 
scriptlet failures from dependent packages.


2) Hardcoded removals after install has the virtue of simplicity,
both in terms of implementation and being rather idiot-proof: installs 
and erasures could be safely interleaved IFF the dependency data from 
packages is perfect. For install-scripts it usually is close enough, but 
much less so for erasure. Given the potentially dramatic outcome of 
early erasure gone wrong, simple-and-stupid doesn't seem so stupid.


- Panu -
___
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: Orphaned packages to be retired (Java packages in 3 weeks)

[Mikolaj Izdebski]

On Tue, Mar 12, 2019 at 11:49 AM Jakub Jelen  wrote:
>
> Is there already a way to package the java application as a module or
> we will really remove all these package from Fedora?

Most of Java packages listed in this thread are already packaged as
modules. Their retirement in rawhide won't directly cause their
removal from distribution.

> I am really not interested in maintaining a whole java frameworks
> stack, but some guidance (not these weekly emails) from java
> maintainers team that took this decision would be appreciated.

Can you elaborate on what kind of guidance do you expect?

There is no "Java maintainers team" in Fedora. Java packages are
maintained by individual packagers. Theoretically there exists a Java
SIG, but its activity is limited to a couple of emails per year, with
significant part of them talking about orphaning or retiring packages.

--
Mikolaj Izdebski
___
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: Updating Rawhide vs GPG keys

[Vít Ondruch]

Dne 11. 03. 19 v 19:29 Kevin Fenzi napsal(a):
> On 3/11/19 4:31 AM, Vít Ondruch wrote:
>> Hi,
>>
>> Can somebody please enlighten me, how to update Rawhide after branching
>> and not using --nogpgcheck?
> Can you expand on the case here?
>
> What should happen is:
>
> * branching
> * f30 repos gets the f31 key


They got the f31 key in -0.4, but the *signed* package with this key
without subsequent changes to the repositories done in -0.5 is not
available anywhere.


> * you update your f30-repos
> * you jump to rawhide and dnf just imports the key.
>
> How did you get on rawhide?
>
>> It seems that Rawhide keys were added in fedora-repos-30-0.4. So this is
>> the package which is still "rawhide" package and has "f31" keys. But
>> this package was not probably signed, because this directory is empty:
>>
>> https://kojipkgs.fedoraproject.org/packages/fedora-repos/30/0.4/data/signed/
> Yeah, no longer shipped packages have their signed packages removed
> after a while to save space. You just want any newer one there.
> https://kojipkgs.fedoraproject.org/packages/fedora-repos/30/0.5/data/signed/cfc659b9/
> for example.


I did this try 30-0.5 of course, but this is wrong, since installing
this package makes F30 from my Rawhide, that is not what I want.

May the the whole problem is, that fedora-gpg-keys has to be updated
together with fedora-repos?


~~~

$ LC_ALL=C.UTF-8 sudo dnf update --disablerepo=rawhide
--enablerepo=updates-testing --release 30
https://kojipkgs.fedoraproject.org/packages/fedora-repos/30/0.5/data/signed/cfc659b9/noarch/fedora-gpg-keys-30-0.5.noarch.rpm
Last metadata expiration check: 0:01:12 ago on Tue Mar 12 12:12:22 2019.
Dependencies resolved.

 Problem: cannot install both fedora-gpg-keys-30-0.5.noarch and
fedora-gpg-keys-30-0.2.noarch
  - package fedora-repos-30-0.2.noarch requires fedora-gpg-keys =
30-0.2, but none of the providers can be installed
  - cannot install the best update candidate for package
fedora-gpg-keys-30-0.2.noarch
  - problem with installed package fedora-repos-30-0.2.noarch
==
 Package   
Architecture 
Version  
Repository   Size
==
Skipping packages with conflicts:
(add '--best --allowerasing' to command line to force their upgrade):
 fedora-gpg-keys   
noarch   
30-0.5   
@commandline    102 k

Transaction Summary
==
Skip  1 Package

Nothing to do.
Complete!

~~~


Which is not what you expect?


Vít



signature.asc
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://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: Orphaned packages to be retired (Java packages in 3 weeks)

[Dominik 'Rathann' Mierzejewski]

On Tuesday, 12 March 2019 at 12:02, Mikolaj Izdebski wrote:
> On Tue, Mar 12, 2019 at 11:49 AM Jakub Jelen  wrote:
> >
> > Is there already a way to package the java application as a module or
> > we will really remove all these package from Fedora?
> 
> Most of Java packages listed in this thread are already packaged as
> modules. Their retirement in rawhide won't directly cause their
> removal from distribution.

Maybe, but it will cause the removal of other packages that depend on
their regular (non-modular) builds. You are forcing the hands of their
maintainers before the infrastructure to make modular packages available
as build dependencies to regular packages is in place to remake their
packages into modules, let them be retired or pick up your orphans. If
it were ready, your moving these packages to modules would be a
non-event for everyone concerned except you. Instead of helping with
that (or just waiting), you are about to cause the retirement of quite a
few packages whose maintainers want nothing to do with Modularity.
That's not excellent.

Regards,
Dominik
-- 
Fedora   https://getfedora.org  |  RPM Fusion  http://rpmfusion.org
There should be a science of discontent. People need hard times and
oppression to develop psychic muscles.
-- from "Collected Sayings of Muad'Dib" by the Princess Irulan
___
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: Orphaned packages to be retired (Java packages in 3 weeks)

[Aleksandar Kurtakov]

On Tue, Mar 12, 2019 at 1:17 PM Dominik 'Rathann' Mierzejewski <
domi...@greysector.net> wrote:

> On Tuesday, 12 March 2019 at 12:02, Mikolaj Izdebski wrote:
> > On Tue, Mar 12, 2019 at 11:49 AM Jakub Jelen  wrote:
> > >
> > > Is there already a way to package the java application as a module or
> > > we will really remove all these package from Fedora?
> >
> > Most of Java packages listed in this thread are already packaged as
> > modules. Their retirement in rawhide won't directly cause their
> > removal from distribution.
>
> Maybe, but it will cause the removal of other packages that depend on
> their regular (non-modular) builds. You are forcing the hands of their
> maintainers before the infrastructure to make modular packages available
> as build dependencies to regular packages is in place to remake their
> packages into modules, let them be retired or pick up your orphans. If
> it were ready, your moving these packages to modules would be a
> non-event for everyone concerned except you. Instead of helping with
> that (or just waiting), you are about to cause the retirement of quite a
> few packages whose maintainers want nothing to do with Modularity.
> That's not excellent.
>

Dominik, that is totally ugly reply to Mikolaj! Whole Java RPM community
(note not only Fedora but Mageia and etc. too) relied on his work to keep
hundreds (or maybe even thousands) of packages rpm installable. And he has
done that for years without ever complaining! Even more he is one of the
most helpful maintainers whenever someone faces an issue. Respect should be
shown when deserved, blaming like that causes nothing but ill feelings.
Everyone should remember that this is *COMMUNITY* project and if/when
someone needs something they should be ready to jump in and do the work -
whether taking packages or helping infra guys or whatever but no one owes
others anything.

P.S. As Eclipse stack maintainers we are directly hit by this and already
working towards turning it into module as we don't have the manpower to
take over the maintainership of pristine rpms that Mikolaj maintains.
Whoever things that's easy job is welcome to try it out!


>
> Regards,
> Dominik
> --
> Fedora   https://getfedora.org  |  RPM Fusion  http://rpmfusion.org
> There should be a science of discontent. People need hard times and
> oppression to develop psychic muscles.
> -- from "Collected Sayings of Muad'Dib" by the Princess Irulan
> ___
> 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
>


-- 
Alexander Kurtakov
Red Hat Eclipse Team
___
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: What pulls in weak dependencies?

[Vít Ondruch]

Dne 09. 03. 19 v 12:41 Vít Ondruch napsal(a):
> Dne 09. 03. 19 v 4:03 Mamoru TASAKA napsal(a):
>> Vít Ondruch wrote on 2019/03/09 8:03:
>>> Hi,
>>>
>>> Running `dnf update`, it tries to install:
>>>
>>> Installing weak dependencies:
>>>   mkpasswd    x86_64 5.4.1-3.fc31
>>> rawhide 39 k
>>>
>>>
>>>
>>> Trying to query for weak dependencies, nothing requires it:
>>>
>>> $ sudo dnf repoquery --whatrecommends mkpasswd
>>> Last metadata expiration check: 0:07:13 ago on Fri Mar  8 23:51:51 2019.
>>>
>>> $ sudo dnf repoquery --supplements mkpasswd
>>> Last metadata expiration check: 0:07:53 ago on Fri Mar  8 23:51:51 2019.
>>>
>>>
>>> So I wonder how I am supposed to know, why DNF is trying to install such
>>> packages.
>>>
>>>
>>
>> $ dnf repoquery --disablerepo=\* --enablerepo=koji-31 --provides
>> mkpasswd 2>/dev/null | while read f ; do echo -n -e "$f\t" ; dnf
>> repoquery --disablerepo=\* --enablerepo=koji-31 --whatrecommends "$f"
>> 2>/dev/null ; echo ; done
>> mkpasswd = 5.4.1-3.fc31   
>> mkpasswd(x86-64) = 5.4.1-3.fc31   
>> whois-mkpasswd = 5.4.1-3.fc31    libxcrypt-0:4.4.4-1.fc31.x86_64
>>
>> So libxcrypt-0:4.4.4-1.fc31.x86_64 Recommends whois-mkpasswd , which
>> is provided by mkpasswd .
>>
> Thank you. That is actually awful command. I complained in this ticket:
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1549851#c10
>
> and on top of that created new ticket requesting providing full
> information about the packages, which anyhow depend on specific package:
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1687070
>
>
> Vít
>

As it turns out, there actually are DNF options for this. Let me
introduce "--depends" and "--whatdepends":

https://bugzilla.redhat.com/show_bug.cgi?id=1687070#c4

Credits goes to DNF team.


Vít
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://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: Orphaned packages to be retired (Java packages in 3 weeks)

[Neal Gompa]

On Tue, Mar 12, 2019 at 7:29 AM Aleksandar Kurtakov  wrote:
>
> On Tue, Mar 12, 2019 at 1:17 PM Dominik 'Rathann' Mierzejewski 
>  wrote:
>>
>> On Tuesday, 12 March 2019 at 12:02, Mikolaj Izdebski wrote:
>> > On Tue, Mar 12, 2019 at 11:49 AM Jakub Jelen  wrote:
>> > >
>> > > Is there already a way to package the java application as a module or
>> > > we will really remove all these package from Fedora?
>> >
>> > Most of Java packages listed in this thread are already packaged as
>> > modules. Their retirement in rawhide won't directly cause their
>> > removal from distribution.
>>
>> Maybe, but it will cause the removal of other packages that depend on
>> their regular (non-modular) builds. You are forcing the hands of their
>> maintainers before the infrastructure to make modular packages available
>> as build dependencies to regular packages is in place to remake their
>> packages into modules, let them be retired or pick up your orphans. If
>> it were ready, your moving these packages to modules would be a
>> non-event for everyone concerned except you. Instead of helping with
>> that (or just waiting), you are about to cause the retirement of quite a
>> few packages whose maintainers want nothing to do with Modularity.
>> That's not excellent.
>
>
> Dominik, that is totally ugly reply to Mikolaj! Whole Java RPM community 
> (note not only Fedora but Mageia and etc. too) relied on his work to keep 
> hundreds (or maybe even thousands) of packages rpm installable. And he has 
> done that for years without ever complaining! Even more he is one of the most 
> helpful maintainers whenever someone faces an issue. Respect should be shown 
> when deserved, blaming like that causes nothing but ill feelings.
> Everyone should remember that this is *COMMUNITY* project and if/when someone 
> needs something they should be ready to jump in and do the work - whether 
> taking packages or helping infra guys or whatever but no one owes others 
> anything.
>
> P.S. As Eclipse stack maintainers we are directly hit by this and already 
> working towards turning it into module as we don't have the manpower to take 
> over the maintainership of pristine rpms that Mikolaj maintains. Whoever 
> things that's easy job is welcome to try it out!
>

This whole process was handled in the worst possible way. To sum up:
* No one knew Java SIG was having manpower issues because Mikolaj
didn't know how to ask for help
* Now it's too late because he orphaned nearly 1700 packages to force
modularization
* This caused everyone dependent on those packages to freak
* And here we are in the bad ending...

We could have avoided the bad ending if at any point there was an
official call for help to increase Java SIG manpower. There wasn't. We
could have avoided this if there was a discussion before the
orphaning. There wasn't.

We could have avoided the bad ending if people dependent on Java
packages were given the opportunity to help. As you say, this is a
community distro. That goes both ways. But that didn't happen.

So here we are, in the bad ending.



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

[Tomas Hozza]

On 10. 3. 2019 19:59, Tomasz Kłoczko wrote:
> On Thu, 28 Feb 2019 at 14:11, Neal Gompa  wrote:
> [..]
>>> tl;dr dhcp 4.4.1 will not require bind-export-libs and will bring 
>>> dhcp-libs-static with bundled version of libisc/libdns/etc
>>>
>>> As ISC dropped support of single thread build of BIND libraries [1] and 
>>> dhcp requires one we decided to not patch dhcp/bind build scripts anymore 
>>> and ship bundled bind libraries just like upstream (ISC) does it. It will 
>>> allow to update BIND in Fedora to newest version. So dhcp 4.4.1 can be 
>>> expected in rawhide/F31 soon!
>>> I'm aware of FPG recommendation to avoid shipping of bundled libraries due 
>>> to its maintenance cost but maintaining of heavy patched build sctipts and 
>>> inability to ship newer versions are even worse.
>>>
>>> I have not find any application in Fedora repository which link with 
>>> libdhcp/libomapi. Please let me know if you aware of any.
>>>
>> Just add the bundled() Provides if it's building with bundled copies,
>> per the policy:
>> https://docs.fedoraproject.org/en-US/packaging-guidelines/#bundling
> 
> I'm only curious (maybe I do not understand something about this
> issue) .. why dhcpd cannot use standard glibc resolver?
> IIRC glibc libresolve is thread safe (if this issue it is about thread
> safe DNS resolution).
> Can someone explain that topic a bit?
> 
> kloczek
> 

ISC DHCP uses BIND libraries e.g. to support Dynamic DNS updates on 
authoritative DNS server when assigning leases to hosts. I don't think that 
glibc resolver would be anyhow useful in this case.

Regards,
Tomas
-- 
Tomas Hozza
Associate Manager, Software Engineering - EMEA ENG Core Services

PGP: 1D9F3C2D
UTC+1 (CET)
Red Hat Inc. http://cz.redhat.com
___
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: Orphaned packages to be retired (Java packages in 3 weeks)

[Aleksandar Kurtakov]

On Tue, Mar 12, 2019 at 1:36 PM Neal Gompa  wrote:

> On Tue, Mar 12, 2019 at 7:29 AM Aleksandar Kurtakov 
> wrote:
> >
> > On Tue, Mar 12, 2019 at 1:17 PM Dominik 'Rathann' Mierzejewski <
> domi...@greysector.net> wrote:
> >>
> >> On Tuesday, 12 March 2019 at 12:02, Mikolaj Izdebski wrote:
> >> > On Tue, Mar 12, 2019 at 11:49 AM Jakub Jelen 
> wrote:
> >> > >
> >> > > Is there already a way to package the java application as a module
> or
> >> > > we will really remove all these package from Fedora?
> >> >
> >> > Most of Java packages listed in this thread are already packaged as
> >> > modules. Their retirement in rawhide won't directly cause their
> >> > removal from distribution.
> >>
> >> Maybe, but it will cause the removal of other packages that depend on
> >> their regular (non-modular) builds. You are forcing the hands of their
> >> maintainers before the infrastructure to make modular packages available
> >> as build dependencies to regular packages is in place to remake their
> >> packages into modules, let them be retired or pick up your orphans. If
> >> it were ready, your moving these packages to modules would be a
> >> non-event for everyone concerned except you. Instead of helping with
> >> that (or just waiting), you are about to cause the retirement of quite a
> >> few packages whose maintainers want nothing to do with Modularity.
> >> That's not excellent.
> >
> >
> > Dominik, that is totally ugly reply to Mikolaj! Whole Java RPM community
> (note not only Fedora but Mageia and etc. too) relied on his work to keep
> hundreds (or maybe even thousands) of packages rpm installable. And he has
> done that for years without ever complaining! Even more he is one of the
> most helpful maintainers whenever someone faces an issue. Respect should be
> shown when deserved, blaming like that causes nothing but ill feelings.
> > Everyone should remember that this is *COMMUNITY* project and if/when
> someone needs something they should be ready to jump in and do the work -
> whether taking packages or helping infra guys or whatever but no one owes
> others anything.
> >
> > P.S. As Eclipse stack maintainers we are directly hit by this and
> already working towards turning it into module as we don't have the
> manpower to take over the maintainership of pristine rpms that Mikolaj
> maintains. Whoever things that's easy job is welcome to try it out!
> >
>
> This whole process was handled in the worst possible way. To sum up:
> * No one knew Java SIG was having manpower issues because Mikolaj
> didn't know how to ask for help
> * Now it's too late because he orphaned nearly 1700 packages to force
> modularization
> * This caused everyone dependent on those packages to freak
> * And here we are in the bad ending...
>
> We could have avoided the bad ending if at any point there was an
> official call for help to increase Java SIG manpower. There wasn't. We
> could have avoided this if there was a discussion before the
> orphaning. There wasn't.
>
> We could have avoided the bad ending if people dependent on Java
> packages were given the opportunity to help. As you say, this is a
> community distro. That goes both ways. But that didn't happen.
>

Hmm,
https://lists.fedoraproject.org/archives/list/java-de...@lists.fedoraproject.org/thread/MQMRQVENBLDRS67WLNQ7EOCMSDI5WIET/
seems that people had a lot of time to act and get involved.


>
> So here we are, in the bad ending.
>
>
>
> --
> 真実はいつも一つ！/ Always, there's only one truth!
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://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
>


-- 
Alexander Kurtakov
Red Hat Eclipse Team
___
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: Updating Rawhide vs GPG keys

[Vít Ondruch]

Dne 12. 03. 19 v 12:14 Vít Ondruch napsal(a):
> Dne 11. 03. 19 v 19:29 Kevin Fenzi napsal(a):
>> On 3/11/19 4:31 AM, Vít Ondruch wrote:
>>> Hi,
>>>
>>> Can somebody please enlighten me, how to update Rawhide after branching
>>> and not using --nogpgcheck?
>> Can you expand on the case here?
>>
>> What should happen is:
>>
>> * branching
>> * f30 repos gets the f31 key
>
> They got the f31 key in -0.4, but the *signed* package with this key
> without subsequent changes to the repositories done in -0.5 is not
> available anywhere.
>
>
>> * you update your f30-repos
>> * you jump to rawhide and dnf just imports the key.
>>
>> How did you get on rawhide?
>>
>>> It seems that Rawhide keys were added in fedora-repos-30-0.4. So this is
>>> the package which is still "rawhide" package and has "f31" keys. But
>>> this package was not probably signed, because this directory is empty:
>>>
>>> https://kojipkgs.fedoraproject.org/packages/fedora-repos/30/0.4/data/signed/
>> Yeah, no longer shipped packages have their signed packages removed
>> after a while to save space. You just want any newer one there.
>> https://kojipkgs.fedoraproject.org/packages/fedora-repos/30/0.5/data/signed/cfc659b9/
>> for example.
>
> I did this try 30-0.5 of course, but this is wrong, since installing
> this package makes F30 from my Rawhide, that is not what I want.
>
> May the the whole problem is, that fedora-gpg-keys has to be updated
> together with fedora-repos?
>
>
> ~~~
>
> $ LC_ALL=C.UTF-8 sudo dnf update --disablerepo=rawhide
> --enablerepo=updates-testing --release 30
> https://kojipkgs.fedoraproject.org/packages/fedora-repos/30/0.5/data/signed/cfc659b9/noarch/fedora-gpg-keys-30-0.5.noarch.rpm
> Last metadata expiration check: 0:01:12 ago on Tue Mar 12 12:12:22 2019.
> Dependencies resolved.
>
>  Problem: cannot install both fedora-gpg-keys-30-0.5.noarch and
> fedora-gpg-keys-30-0.2.noarch
>   - package fedora-repos-30-0.2.noarch requires fedora-gpg-keys =
> 30-0.2, but none of the providers can be installed
>   - cannot install the best update candidate for package
> fedora-gpg-keys-30-0.2.noarch
>   - problem with installed package fedora-repos-30-0.2.noarch
> ==
>  Package   
> Architecture 
> Version  
> Repository   Size
> ==
> Skipping packages with conflicts:
> (add '--best --allowerasing' to command line to force their upgrade):
>  fedora-gpg-keys   
> noarch   
> 30-0.5   
> @commandline    102 k
>
> Transaction Summary
> ==
> Skip  1 Package
>
> Nothing to do.
> Complete!
>
> ~~~
>
>
> Which is not what you expect?


https://src.fedoraproject.org/rpms/fedora-repos/pull-request/29


V.



>
>
> Vít
>
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://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


signature.asc
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://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: Chromium C++ help needed

[Christophe de Dinechin]

> On 11 Mar 2019, at 18:16, Tom Callaway  wrote:
> 
> Hi folks,
> 
> I spent some time this weekend trying to get Chromium 72 building on Fedora, 
> but I kept running into a C++ issue that I was not able to resolve. This 
> happened with gcc-9.0.1-0.8.fc30.x86_64 and gcc-8.3.1-2.fc29.x86_64. 
> 
> Here's a sample of the error (it happens in a few places), from Fedora 30:
> 
> In file included from 
> ../../base/trace_event/trace_event_system_stats_monitor.h:15,
> from ../../base/trace_event/trace_event.h:26,
> from ../../base/threading/scoped_blocking_call.cc:11:
> ../../base/trace_event/trace_log.h: In constructor 
> 'base::ScopedBlockingCall::ScopedBlockingCall(base::BlockingType)':
> ../../base/threading/scoped_blocking_call.cc:88:5:   in 'constexpr' expansion 
> of 'base::trace_event::TraceLog::GetBuiltinCategoryEnabled(((const 
> char*)"base"))'
> ../../base/trace_event/trace_log.h:215:25: error: '((& 
> base::trace_event::CategoryRegistry::categories_[7]) != 0)' is not a constant 
> expression

It looks like the compiler is not smart enough to detect that this is the 
address of a static object, defined at line 92744 of your preprocessed file as:

 static TraceCategory categories_[kMaxCategories];

whereas it is smart enough to go through GetBuiltnCategoryByName and figure out 
index 7 from the name…

I tried to compile your preprocessed fragment with both clang or gcc. 
Interestingly:

1) Without your command-line options, I don’t see the same error.

2) With your command-line options, I see the error with gcc, but not with clang.

So I suspect a compiler bug.



>  215 | if (builtin_category)
> | ^
> 
> Now, chromium isn't the easiest code base to work with, but what seems to be 
> happening is that this code calls one of the TRACE_EVENT macros, like this 
> from base/threading/scoped_blocking_call.cc:
> 
> TRACE_EVENT_BEGIN1("base", "ScopedBlockingCall", "blocking_type", 
> static_cast(blocking_type));
> 
> Those macros are defined in base/trace_event/common/trace_event_common.h:
> 
> #define TRACE_EVENT_BEGIN1(category_group, name, arg1_name, arg1_val) \
>  INTERNAL_TRACE_EVENT_ADD(TRACE_EVENT_PHASE_BEGIN, category_group, name, \
>   TRACE_EVENT_FLAG_NONE, arg1_name, arg1_val)
> 
> INTERNAL_TRACE_EVENT_ADD() is defined in base/trace_event/trace_event.h:
> 
> / Implementation detail: internal macro to create static category and add
> // event if the category is enabled.
> #define INTERNAL_TRACE_EVENT_ADD(phase, category_group, name, flags, ...)  \
>  do { \
>INTERNAL_TRACE_EVENT_GET_CATEGORY_INFO(category_group);\
>if (INTERNAL_TRACE_EVENT_CATEGORY_GROUP_ENABLED()) {   \
>  trace_event_internal::AddTraceEvent( \
>  phase, INTERNAL_TRACE_EVENT_UID(category_group_enabled), name,   \
>  trace_event_internal::kGlobalScope, trace_event_internal::kNoId, \
>  flags, trace_event_internal::kNoId, ##__VA_ARGS__);  \
>}  \
>  } while (0)
> 
> INTERNAL_TRACE_EVENT_GET_CATEGORY_INFO is also defined in 
> base/trace_event/trace_event.h:
> 
> #define INTERNAL_TRACE_EVENT_GET_CATEGORY_INFO(category_group)
>  \
>  static_assert(   
> \
>  base::trace_event::BuiltinCategories::IsAllowedCategory(category_group), 
> \
>  "Unknown tracing category is used. Please register your "
> \
>  "category in base/trace_event/builtin_categories.h");
> \
>  constexpr const unsigned char* INTERNAL_TRACE_EVENT_UID( 
> \
>  k_category_group_enabled) =  
> \
>  base::trace_event::TraceLog::GetBuiltinCategoryEnabled(category_group);  
> \
>  const unsigned char* INTERNAL_TRACE_EVENT_UID(category_group_enabled);   
> \
>  INTERNAL_TRACE_EVENT_GET_CATEGORY_INFO_MAYBE_AT_COMPILE_TIME(
> \
>  category_group, INTERNAL_TRACE_EVENT_UID(k_category_group_enabled),  
> \
>  INTERNAL_TRACE_EVENT_UID(category_group_enabled));
> 
> Finally, inside here, it calls 
> base::trace_event::TraceLog::GetBuiltinCategoryEnabled(), which is defined in 
> base/trace_event/trace_log.h:
> 
>  // Called by TRACE_EVENT* macros, don't call this directly.
>  // The name parameter is a category group for example:
>  // TRACE_EVENT0("renderer,webkit", "WebViewImpl::HandleInputEvent")
>  static const unsigned char* GetCategoryGroupEnabled(const char* name);
>  static const char* GetCategoryGroupName(
>  const unsigned char* category_group_enabled);
>  static constexpr const unsigned char* GetBuiltinCategoryEnabled(
>  const char* name) {
>TraceCategory* builtin_category =
>  

Re: Updating Rawhide vs GPG keys

[Vít Ondruch]

Dne 12. 03. 19 v 12:46 Vít Ondruch napsal(a):
>
>
> Dne 12. 03. 19 v 12:14 Vít Ondruch napsal(a):
>> Dne 11. 03. 19 v 19:29 Kevin Fenzi napsal(a):
>>> On 3/11/19 4:31 AM, Vít Ondruch wrote:
 Hi,

 Can somebody please enlighten me, how to update Rawhide after branching
 and not using --nogpgcheck?
>>> Can you expand on the case here?
>>>
>>> What should happen is:
>>>
>>> * branching
>>> * f30 repos gets the f31 key
>> They got the f31 key in -0.4, but the *signed* package with this key
>> without subsequent changes to the repositories done in -0.5 is not
>> available anywhere.
>>
>>
>>> * you update your f30-repos
>>> * you jump to rawhide and dnf just imports the key.
>>>
>>> How did you get on rawhide?
>>>
 It seems that Rawhide keys were added in fedora-repos-30-0.4. So this is
 the package which is still "rawhide" package and has "f31" keys. But
 this package was not probably signed, because this directory is empty:

 https://kojipkgs.fedoraproject.org/packages/fedora-repos/30/0.4/data/signed/
>>> Yeah, no longer shipped packages have their signed packages removed
>>> after a while to save space. You just want any newer one there.
>>> https://kojipkgs.fedoraproject.org/packages/fedora-repos/30/0.5/data/signed/cfc659b9/
>>> for example.
>> I did this try 30-0.5 of course, but this is wrong, since installing
>> this package makes F30 from my Rawhide, that is not what I want.


I should have better explained this. Updating fedora-repos and
fedora-repos-rawhide together with fedora-gpg-keys to this specific
version makes F30 from Rawhide by disabling the "rawhide" repo (and
enabling the fedora repo, which should not be problem at all). Then all
the packages from F30 are taken including fedora-release, which then
make F30 from Rawhide.


V.


>>
>> May the the whole problem is, that fedora-gpg-keys has to be updated
>> together with fedora-repos?
>>
>>
>> ~~~
>>
>> $ LC_ALL=C.UTF-8 sudo dnf update --disablerepo=rawhide
>> --enablerepo=updates-testing --release 30
>> https://kojipkgs.fedoraproject.org/packages/fedora-repos/30/0.5/data/signed/cfc659b9/noarch/fedora-gpg-keys-30-0.5.noarch.rpm
>> Last metadata expiration check: 0:01:12 ago on Tue Mar 12 12:12:22 2019.
>> Dependencies resolved.
>>
>>  Problem: cannot install both fedora-gpg-keys-30-0.5.noarch and
>> fedora-gpg-keys-30-0.2.noarch
>>   - package fedora-repos-30-0.2.noarch requires fedora-gpg-keys =
>> 30-0.2, but none of the providers can be installed
>>   - cannot install the best update candidate for package
>> fedora-gpg-keys-30-0.2.noarch
>>   - problem with installed package fedora-repos-30-0.2.noarch
>> ==
>>  Package   
>> Architecture 
>> Version  
>> Repository   Size
>> ==
>> Skipping packages with conflicts:
>> (add '--best --allowerasing' to command line to force their upgrade):
>>  fedora-gpg-keys   
>> noarch   
>> 30-0.5   
>> @commandline    102 k
>>
>> Transaction Summary
>> ==
>> Skip  1 Package
>>
>> Nothing to do.
>> Complete!
>>
>> ~~~
>>
>>
>> Which is not what you expect?
>
>
> https://src.fedoraproject.org/rpms/fedora-repos/pull-request/29
>
>
> V.
>


signature.asc
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://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: Non-responsive maintainer Chris Lalancette (clalance)

[Vít Ondruch]

Dne 12. 03. 19 v 11:11 Miro Hrončok napsal(a):
> https://bugzilla.redhat.com/show_bug.cgi?id=1659737
>
> Anyone knows how to contact the maintainer?
>

Last time I was in contact with Chris was via his email:

clalance...@gmail.com

He is still active from time to time:

https://src.fedoraproject.org/rpms/rubygem-ruby-libvirt/commits/master


Vít
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://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: F31 System-Wide Change proposal: Enable Compiler Security hardening flags by default in G

[Vít Ondruch]

Will it help to mitigate issues such as:

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

and mitigate workarounds such as:

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

That would be wonderful.


Also, while OT to this specific change, I would love to have ability to
have some compiler flags tailored to my environment. E.g. enabled
optimizations specific to my CPU. That could enable potential of JIT
compilation in Ruby and possibly everywhere else where compiler is
involved in installation some extensions from 3rd party repositories.


Vít


Dne 11. 03. 19 v 18:56 Ben Cotton napsal(a):
> https://fedoraproject.org/wiki/Changes/HardenedCompiler
>
> == Summary ==
> By Default enable a few security hardening flags which are used with GCC.
>
> == Owner ==
> * Name: [[User:huzaifas|Huzaifa Sidhpurwala]]
> * Email: huzai...@redhat.com
> * Release notes owner: huzai...@redhat.com
>
>
> == Detailed Description ==
> Currently GCC does not enable any security hardening flags by default.
> They have to be explicitly enabled by the developers one-by-one.
> Ubuntu (https://wiki.ubuntu.com/ToolChain/CompilerFlags) however
> enables them and therefore has a hardened compiler by default. Each of
> these options can be explicitly disabled if required by the developer
> via a GCC command line flag.  I am currently proposing the following
> flags be enabled by default.
>
> '''-Wformat -Wformat-security -fstack-protector-strong
> --param=ssp-buffer-size=4 -D_FORTIFY_SOURCE=2 -O'
>
> {| class="wikitable"
> |-
> ! No !! Flag !! Use !! How to disable
> |-
> | 1 || -Wformat || Check calls to "printf" and "scanf", etc., to make
> sure that the arguments supplied have types appropriate to the format
> string specified, and that the conversions specified in the  format
> string make sense. || -Wno-format
> |-
> | 2 || -Wformat-security || If -Wformat is specified, also warn about
> uses of format functions that represent possible security problems.
> || -Wno-format should disable this as well
> |-
> | 3 || -fstack-protector-strong || Like -fstack-protector but includes
> additional functions to be protected --- those that have local array
> definitions, or have references to local frame addresses.
> || -fno-stack-protector
> |}
>
>
> == Benefit to Fedora ==
> We provide better security both for our packages and for
> applications/programs which users are building.
>
> == Scope ==
> * Proposal owners: Patch gcc to enable these options by default. Patch
> should be very simple, since the compile/link code isnt actually
> touched.
> * Other developers: Developers need to ensure that Fedora package is
> built and if any build failures they are corrected
> * Release engineering: [https://pagure.io/releng/issue/8204 #8204]
> * Policies and guidelines: The policies and guidelines do not need to
> be updated.
> * Trademark approval: Not needed for this change
>
> == Upgrade/compatibility impact ==
> None
>
> == How To Test ==
> Run "gcc -Q -v " to check if these flags are enabled by default
>
> == User Experience ==
> Fedora is more secure because the entire distribution is compiled with
> the correct security technologies enabled. Developers dont have to
> worry about enabling the right flags when they compile their
> application in Fedora because the compiler has them enabled by
> default.
>
> == Dependencies ==
> All packages will be rebuild with new GCC options.
>
> == Contingency Plan ==
> * Contingency mechanism: Roll back the GCC options and use the default ones.
> * Contingency deadline: Beta Feeze
> * Blocks release? No
>
>
>
>
___
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

Agenda for Tuesday's Modularity Team Meeting (2019-03-12)

[Nils Philippsen]

Find below a list of topics which are planned to be discussed in the
Fedora Modularity Team meeting on Tuesday at 15:00 UTC in
#fedora-meeting-3 on irc.freenode.net.

To find out when this is in your local time zone, check the Fedora
Calendar (if you've set it and are logged in):
  https://apps.fedoraproject.org/calendar/modularity/#m5249

Alternatively, to convert UTC to your local time zone, take a look at
  http://fedoraproject.org/wiki/UTCHowto

or run:
  date -d 'Tuesday 15:00 UTC'

Links to all issues below can be found at:
  https://pagure.io/modularity/report/meeting_agenda

= Discussed and Voted =
N/A

= Followups =

#topic #112 Discussion: Module lifecycles 
#link https://pagure.io/modularity/issue/112
.modularity 112
#link https://pagure.io/fesco/issue/2027

= New business =

#topic #126 Automatically track refs in a module yaml file
.modularity 126
#link https://pagure.io/modularity/issue/126

= Open Floor =

For more complete details, please visit each individual
issue.  The report of the agenda items can be found at
https://pagure.io/modularity/report/meeting_agenda

If you would like to add something to this agenda, you can file a new
issue at https://pagure.io/modularity/issues, or bring it up at the end
of the meeting during the open floor topic. Note that the meeting is
one hour long and issues we don't get around to discussing may be
deferred until the following meeting.

-- 
Nils Philippsen"Those who would give up Essential Liberty to
Software Engineer   purchase a little Temporary Safety, deserve neither
Red Hat Liberty nor Safety."  --  Benjamin Franklin, 1759
PGP fingerprint:C4A8 9474 5C4C ADE3 2B8F  656D 47D8 9B65 6951 3011
___
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: Orphaned packages to be retired (Java packages in 3 weeks)

[Mikolaj Izdebski]

On Tue, Mar 12, 2019 at 12:36 PM Neal Gompa  wrote:
> This whole process was handled in the worst possible way. To sum up:
> * No one knew Java SIG was having manpower issues because Mikolaj
> didn't know how to ask for help

You did not know that, but the situation in Java SIG is well known to
Java SIG members. Statistics speak for themselves.

For example, the packager who owns the most of Java packages (point of
contacts for 480 Java packages) made his last commit in February 2017.
The second maintainer (PoC for 94 Java packages) had last commit in
2015. The fourth (PoC of 55 packages) - last commit in March 2017. And
so on.

Situation on mailing list is not much better. Less than 20 mail
threads in each of years 2018 and 2017. Compare with more than 150
threads in year 2013.

The last Java SIG IRC meeting took place in February 2013.

> * Now it's too late because he orphaned nearly 1700 packages to force
> modularization

I did not orphan that many packages. I orphaned about 250 packages only.

It is not too late for anything. Orphaned packages can still be
adopted. That's the whole point of this thread.

> We could have avoided the bad ending if at any point there was an
> official call for help to increase Java SIG manpower. There wasn't. We
> could have avoided this if there was a discussion before the
> orphaning. There wasn't.

We don't have any official process for calling for help. Other distros
(at least Debian) have it, but not Fedora.

Discussion requires more than one participating party. I started a
thread on java-devel list where I explained the situation and my plans
in detail. There was no reply on the list, not a single message. I
only had one or two private conversations about this problem.

> We could have avoided the bad ending if people dependent on Java
> packages were given the opportunity to help. As you say, this is a
> community distro. That goes both ways. But that didn't happen.

IMHO I've been very patient. I've given the community a lot of
opportunity to help. I never refused any help. I was and I am still
working with new contributors that want to become packagers.

--
Mikolaj
___
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: Orphaned packages to be retired (Java packages in 3 weeks)

[Neal Gompa]

On Tue, Mar 12, 2019 at 8:35 AM Mikolaj Izdebski  wrote:
>
> On Tue, Mar 12, 2019 at 12:36 PM Neal Gompa  wrote:
> > This whole process was handled in the worst possible way. To sum up:
> > * No one knew Java SIG was having manpower issues because Mikolaj
> > didn't know how to ask for help
>
> You did not know that, but the situation in Java SIG is well known to
> Java SIG members. Statistics speak for themselves.
>

I'm not a Java SIG member, so how would I know?

> For example, the packager who owns the most of Java packages (point of
> contacts for 480 Java packages) made his last commit in February 2017.
> The second maintainer (PoC for 94 Java packages) had last commit in
> 2015. The fourth (PoC of 55 packages) - last commit in March 2017. And
> so on.
>
> Situation on mailing list is not much better. Less than 20 mail
> threads in each of years 2018 and 2017. Compare with more than 150
> threads in year 2013.
>
> The last Java SIG IRC meeting took place in February 2013.
>
> > * Now it's too late because he orphaned nearly 1700 packages to force
> > modularization
>
> I did not orphan that many packages. I orphaned about 250 packages only.
>

Sorry, you're right, it affects nearly that many though.

> It is not too late for anything. Orphaned packages can still be
> adopted. That's the whole point of this thread.
>
> > We could have avoided the bad ending if at any point there was an
> > official call for help to increase Java SIG manpower. There wasn't. We
> > could have avoided this if there was a discussion before the
> > orphaning. There wasn't.
>
> We don't have any official process for calling for help. Other distros
> (at least Debian) have it, but not Fedora.
>

The reason Debian has one is because people generally don't know how
to work with each other there. That said, if we need a process for
this for some people to be more comfortable, then that probably should
be requested from FESCo.

> Discussion requires more than one participating party. I started a
> thread on java-devel list where I explained the situation and my plans
> in detail. There was no reply on the list, not a single message. I
> only had one or two private conversations about this problem.
>
> > We could have avoided the bad ending if people dependent on Java
> > packages were given the opportunity to help. As you say, this is a
> > community distro. That goes both ways. But that didn't happen.
>
> IMHO I've been very patient. I've given the community a lot of
> opportunity to help. I never refused any help. I was and I am still
> working with new contributors that want to become packagers.
>

At the risk of overwhelming myself with yet another SIG (I'm in
Python, Go, and Rust already!), I'm willing to help as a SIG member if
that's what it takes to prevent this. I don't know much about Java
packaging (I have only a single Java based package), though.


-- 
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://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: Non-responsive maintainer Chris Lalancette (clalance)

[Miro Hrončok]

On 12. 03. 19 13:44, Chris Lalancette wrote:

Sorry for not responding earlier.

I'm not really involved with imagefactory at all, though I am still the 
maintainer of Oz.  As Daniel pointed out, you'll want to start with Ian Mcleod 
for that package (he can point you in the right direction).


Thank You. Could you please give the package to Ian, so there is no such 
confusion in the future?


--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://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: Updating Rawhide vs GPG keys

[Colin Walters]

On Mon, Mar 11, 2019, at 2:46 PM, Fabio Valentini wrote:
> 
> I'm having a similar problem, but with Silverblue / rawhide.
> 
> I installed the system when rawhide was still f30, but now I can't run 
> "rpm-ostree upgrade" anymore, due to this error:
> 
>  Enabled rpm-md repositories: rawhide
>  Updating metadata for 'rawhide'... done
>  error: Failed to download gpg key for repo 'rawhide': Curl error (37): 
> Couldn't read a file:// file for 
> file:///etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-31-x86_64 [Couldn't open 
> file /etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-31-x86_64]

Hi, edit /etc/ostree/remotes.d/fedora-workstation.conf to look like this:

https://github.com/coreos/fedora-coreos-tracker/issues/143#issuecomment-461148282

This will fix the GPG key issue and also give you much faster updates.
We have work in flight to try to ship this by default.
___
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: Orphaned packages to be retired (Java packages in 3 weeks)

[Jakub Jelen]

On Tue, 2019-03-12 at 13:43 +0200, Aleksandar Kurtakov wrote:
> On Tue, Mar 12, 2019 at 1:36 PM Neal Gompa 
> wrote:
> 
> > On Tue, Mar 12, 2019 at 7:29 AM Aleksandar Kurtakov <
> > akurt...@redhat.com>
> > wrote:
> > > On Tue, Mar 12, 2019 at 1:17 PM Dominik 'Rathann' Mierzejewski <
> > domi...@greysector.net> wrote:
> > > > On Tuesday, 12 March 2019 at 12:02, Mikolaj Izdebski wrote:
> > > > > On Tue, Mar 12, 2019 at 11:49 AM Jakub Jelen <
> > > > > jje...@redhat.com>
> > wrote:
> > > > > > Is there already a way to package the java application as a
> > > > > > module
> > or
> > > > > > we will really remove all these package from Fedora?
> > > > > 
> > > > > Most of Java packages listed in this thread are already
> > > > > packaged as
> > > > > modules. Their retirement in rawhide won't directly cause
> > > > > their
> > > > > removal from distribution.
> > > > 
> > > > Maybe, but it will cause the removal of other packages that
> > > > depend on
> > > > their regular (non-modular) builds. You are forcing the hands
> > > > of their
> > > > maintainers before the infrastructure to make modular packages
> > > > available
> > > > as build dependencies to regular packages is in place to remake
> > > > their
> > > > packages into modules, let them be retired or pick up your
> > > > orphans. If
> > > > it were ready, your moving these packages to modules would be a
> > > > non-event for everyone concerned except you. Instead of helping
> > > > with
> > > > that (or just waiting), you are about to cause the retirement
> > > > of quite a
> > > > few packages whose maintainers want nothing to do with
> > > > Modularity.
> > > > That's not excellent.
> > > 
> > > Dominik, that is totally ugly reply to Mikolaj! Whole Java RPM
> > > community
> > (note not only Fedora but Mageia and etc. too) relied on his work
> > to keep
> > hundreds (or maybe even thousands) of packages rpm installable. And
> > he has
> > done that for years without ever complaining! Even more he is one
> > of the
> > most helpful maintainers whenever someone faces an issue. Respect
> > should be
> > shown when deserved, blaming like that causes nothing but ill
> > feelings.
> > > Everyone should remember that this is *COMMUNITY* project and
> > > if/when
> > someone needs something they should be ready to jump in and do the
> > work -
> > whether taking packages or helping infra guys or whatever but no
> > one owes
> > others anything.
> > > P.S. As Eclipse stack maintainers we are directly hit by this and
> > already working towards turning it into module as we don't have the
> > manpower to take over the maintainership of pristine rpms that
> > Mikolaj
> > maintains. Whoever things that's easy job is welcome to try it out!
> > 
> > This whole process was handled in the worst possible way. To sum
> > up:
> > * No one knew Java SIG was having manpower issues because Mikolaj
> > didn't know how to ask for help
> > * Now it's too late because he orphaned nearly 1700 packages to
> > force
> > modularization
> > * This caused everyone dependent on those packages to freak
> > * And here we are in the bad ending...
> > 
> > We could have avoided the bad ending if at any point there was an
> > official call for help to increase Java SIG manpower. There wasn't.
> > We
> > could have avoided this if there was a discussion before the
> > orphaning. There wasn't.
> > 
> > We could have avoided the bad ending if people dependent on Java
> > packages were given the opportunity to help. As you say, this is a
> > community distro. That goes both ways. But that didn't happen.
> > 
> 
> Hmm,
> https://lists.fedoraproject.org/archives/list/java-de...@lists.fedoraproject.org/thread/MQMRQVENBLDRS67WLNQ7EOCMSDI5WIET/
> seems that people had a lot of time to act and get involved.

Unfortunately not everyone who happens to maintain a java package is in
the java SIG and reading the mails there so I think this mail should
have been sent at least to fedora-devel too, maybe even announce since
it is touching so many packages (dependencies).

I used to have one java package inherited from inactive maintainer then
one more and now comes third. I have them because I want to be able to
use and update my application in Fedora. I really do not care if they
will be built in Fedora or Arbitrary branching.

I see that Mikolaj already did a lot of work of moving his packages to
the modules, so a mail with simple instructions "this is a list of
things that I did for my packages and if you depend on them, do it
also", would save many maintainers as me hours of searching the sparse
modularity documentation.

If there are no such steps, I will jump for the packages that I need,
but if the Java in Fedora future should be modular, lets do that. But
remember: We do not know how.

Regards,
-- 
Jakub Jelen
Software Engineer
Security Technologies
Red Hat, Inc.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to d

Re: Updating Rawhide vs GPG keys

[Fabio Valentini]

On Tue, Mar 12, 2019 at 1:55 PM Colin Walters  wrote:

>
>
> On Mon, Mar 11, 2019, at 2:46 PM, Fabio Valentini wrote:
> >
> > I'm having a similar problem, but with Silverblue / rawhide.
> >
> > I installed the system when rawhide was still f30, but now I can't run
> > "rpm-ostree upgrade" anymore, due to this error:
> >
> >  Enabled rpm-md repositories: rawhide
> >  Updating metadata for 'rawhide'... done
> >  error: Failed to download gpg key for repo 'rawhide': Curl error (37):
> > Couldn't read a file:// file for
> > file:///etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-31-x86_64 [Couldn't open
> > file /etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-31-x86_64]
>
> Hi, edit /etc/ostree/remotes.d/fedora-workstation.conf to look like this:
>
>
> https://github.com/coreos/fedora-coreos-tracker/issues/143#issuecomment-461148282
>
> This will fix the GPG key issue and also give you much faster updates.
> We have work in flight to try to ship this by default.
>

Thanks for the response, but that didn't help with dnf failing the GPG
check.
I think ugrading from f30-rawhide to f31-rawhide is broken in general - I
had to disable gpgchecks for _both_ the ostree remote and the rawhide dnf
repo to make `rpm-ostree upgrade` succeed.

Fabio


> ___
> 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
>
___
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: Orphaned packages to be retired (Java packages in 3 weeks)

[Randy Barlow]

On Tue, 2019-03-12 at 12:16 +0100, Dominik 'Rathann' Mierzejewski
wrote:
> Maybe, but it will cause the removal of other packages that depend on
> their regular (non-modular) builds. You are forcing the hands of
> their
> maintainers before the infrastructure to make modular packages
> available
> as build dependencies to regular packages is in place to remake their
> packages into modules, let them be retired or pick up your orphans.
> If
> it were ready, your moving these packages to modules would be a
> non-event for everyone concerned except you. Instead of helping with
> that (or just waiting), you are about to cause the retirement of
> quite a
> few packages whose maintainers want nothing to do with Modularity.
> That's not excellent.

It's important to keep in mind that many of us volunteer to work on
Fedora, including those of us who work at Red Hat (and even including
those of us who work at Red Hat full time on Fedora!) I do personally
wish we had RPM maintainers for these Java packages, but I don't think
we should make demands from our volunteers. That's not how a community
project works. I think it's OK to express that we wish there were RPMs
for these packages, but we shouldn't blame any particular person when
that doesn't happen. Things happen in open source when people do the
work to make those things happen. As much as I wish we could save these
packages, I am not going to choose to use my time that way. So the most
I would say about it is "it'd be nice if someone else volunteered to do
that work".

I sometimes receive bug reports in Bodhi where the reporter has a
demanding attitude. I welcome bug reports, but I also have to be honest
that maintaining Bodhi is far more work than the people who show up to
do it can handle.  Most things in Bodhi will only happen if someone
volunteers to write the code, so most of the bugs we get filed aren't
going to get worked on. It's not helpful to either party if the
reporter has a demanding attitude.


signature.asc
Description: This is a digitally signed message part
___
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: Can't push to batched an Fedora 30 update?

[Randy Barlow]

On Mon, 2019-03-11 at 21:55 +0100, Tomasz Torcz wrote:
>   Hmm, rebulding container on config change? Sounds fishy.
> Have you tried putting production.ini into ConfigMap?

It is in a configmap:

https://infrastructure.fedoraproject.org/cgit/ansible.git/tree/roles/bodhi2/base/templates/configmap.yml#n108

The reason I rebuilt the container is that I don't have ACLs to access
OpenShift directly and must interact with it via some Ansible
playbooks, and the only lever I can pull here that I'm aware of builds
a new container.


signature.asc
Description: This is a digitally signed message part
___
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: Orphaned packages to be retired (Java packages in 3 weeks)

[Miroslav Suchý]

Dne 12. 03. 19 v 12:34 Neal Gompa napsal(a):
> This whole process was handled in the worst possible way. To sum up:
> * No one knew Java SIG was having manpower issues because Mikolaj
> didn't know how to ask for help
> * Now it's too late because he orphaned nearly 1700 packages to force
> modularization
> * This caused everyone dependent on those packages to freak
> * And here we are in the bad ending...

Alternative sum up:
* People (not just Mikolaj) started using modules, while Koji cannot use 
modular repos.

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

Fedora 30 chroots now available in Copr

[Jakub Kadlcik]

Hello,
I've just enabled F30 chroots in Copr.

The projects that have "Follow Fedora branching" enabled, have them
automatically activated as well builds from rawhide forked into them.

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

Debian and Fedora distro development

[Przemek Klosowski]

A longtime Debian developer Michael Stapelberg described his 
frustrations with their distribution development environment


https://michael.stapelberg.ch/posts/2019-03-10-debian-winding-down/

Many points are spookily similar to issues in Fedora, as discussed on 
this list, for instance the automation of large-scale changes, 
especially as it intersects with individual packagers' autonomy. I 
thought it's a good read for people who care about Fedora infrastructure.

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

[Modularity] Team IRC meeting minutes (2019-03-12)

[Nils Philippsen]

#fedora-meeting-3: Weekly Meeting of the Modularity Team



Meeting started by nils at 15:00:00 UTC.

Minutes: 
https://meetbot.fedoraproject.org/fedora-meeting-3/2019-03-12/modularity.2019-03-12-15.00.html
Minutes (text): 
https://meetbot.fedoraproject.org/fedora-meeting-3/2019-03-12/modularity.2019-03-12-15.00.txt
Log: 
https://meetbot.fedoraproject.org/fedora-meeting-3/2019-03-12/modularity.2019-03-12-15.00.log.html


Meeting summary
---
* Roll Call  (nils, 15:00:00)

* Agenda  (nils, 15:04:04)
  * #112 Discussion: Module lifecycles  (nils, 15:04:05)
  * #126 Automatically track refs in a module yaml file  (nils,
15:04:05)

* #112 Discussion: Module lifecycles  (nils, 15:05:18)
  * LINK: https://pagure.io/modularity/issue/112   (nils, 15:05:18)
  * LINK: https://pagure.io/fesco/issue/2027   (nils, 15:05:18)
  * proposed to leave EOL field empty until maintainers know they want
to retire a module, and when  (nils, 15:09:23)
  * still being reviewed by FESCo  (nils, 15:09:47)

* #126 Automatically track refs in a module yaml file  (nils, 15:25:06)
  * LINK: https://pagure.io/modularity/issue/126   (nils, 15:25:07)
  * ACTION: contyk updates the ticket with the available options  (nils,
15:54:20)
  * revisit this issue next week  (nils, 15:54:38)

Meeting ended at 15:57:36 UTC.




Action Items

* contyk updates the ticket with the available options




Action Items, by person
---
* contyk
  * contyk updates the ticket with the available options
* **UNASSIGNED**
  * (none)




People Present (lines said)
---
* asamalik (58)
* nils (57)
* contyk (40)
* sgallagh (39)
* langdon (22)
* zodbot (12)




Generated by `MeetBot`_ 0.1.4

.. _`MeetBot`: http://wiki.debian.org/MeetBot
-- 
Nils Philippsen"Those who would give up Essential Liberty to
Software Engineer   purchase a little Temporary Safety, deserve neither
Red Hat Liberty nor Safety."  --  Benjamin Franklin, 1759
PGP fingerprint:C4A8 9474 5C4C ADE3 2B8F  656D 47D8 9B65 6951 3011


___
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

perl-true license change

[Paul Howarth]

For your information:

perl-true's license has changed from "Same as Perl" (GPL+ or Artistic) to 
"Artistic 2.0".

This happened when the version changed from 0.18 to 1.0.1 today. I've
built the newly-licensed version in f30 and rawhide.

Regards, Paul.


___
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: Debian and Fedora distro development

[Zbigniew Jędrzejewski-Szmek]

On Tue, Mar 12, 2019 at 11:52:50AM -0400, Przemek Klosowski wrote:
> A longtime Debian developer Michael Stapelberg described his
> frustrations with their distribution development environment
> 
> https://michael.stapelberg.ch/posts/2019-03-10-debian-winding-down/
> 
> Many points are spookily similar to issues in Fedora, as discussed
> on this list, for instance the automation of large-scale changes,
> especially as it intersects with individual packagers' autonomy. I
> thought it's a good read for people who care about Fedora
> infrastructure.

I think Fedora has managed to avoid many of the issues Michael list:

- the management of package sources is centralized and uniform.

- we have a formalized process for wide-scale changes, and
  provenpackagers who do push such things through. In fact, if a
  packager wants to do some massive change, this is often used as
  justification for getting pp privs.

- we generally don't rely solely on individual packagers to implement
  new paradigms. We use a combination of scripted changes, PRs in
  dist git, bugzillas, and nagging. If we don't do the automatically,
  this is most likely because we don't know how to automate it, and
  not because we don't have the ability to push automatic changes.

- we're very slowly moving towards automatic packaging. There's still
  a lot of manual work, but tings are improving all the time. It
  depends on the language stack, but for example in the python world a
  lot of the packaging is now done using a standard template with a
  few macros, and we're slowly moving towards autogeneration based on
  upstream description. Rust and go and some other languages are even
  more automated.

  If one of the proposals for BuildRequires generation goes through,
  the packaging landscape will shift even more.

And in general, Fedora *is* able to make a choice. We have one dist-git,
one init system, one default compiler, one kernel, soon one python
version, etc. We don't have insanities like local maintainer builds,
binNMUs without changelog entries, packages without version control.
And in extreme cases of non-cooperating maintainers, FPC and FESCo
will put their feet down to force things to happen.

We do have other problems... but I think ours are quite a bit
different than Debian's.

Zbyszek
___
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: Debian and Fedora distro development

[Nicolas Mailhot]

Le 2019-03-12 17:34, Zbigniew Jędrzejewski-Szmek a écrit :


I think Fedora has managed to avoid many of the issues Michael list:


…


We do have other problems... but I think ours are quite a bit
different than Debian's.


Yes, we do have the same class of problems (old infra and processes that 
need revamping now¹ to keep an attractive contributor experience), but 
the actual list is not the same


¹ As opposed to “somewhat in the future” that tends to become “never” in 
a mature organisation. When it reaches “never” the organisation starts 
dying


--
Nicolas Mailhot
___
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: Orphaned packages to be retired (Java packages in 3 weeks)

[Christopher]

On Tue, Mar 12, 2019 at 11:43 AM Miroslav Suchý  wrote:
>
> Dne 12. 03. 19 v 12:34 Neal Gompa napsal(a):
> > This whole process was handled in the worst possible way. To sum up:
> > * No one knew Java SIG was having manpower issues because Mikolaj
> > didn't know how to ask for help
> > * Now it's too late because he orphaned nearly 1700 packages to force
> > modularization
> > * This caused everyone dependent on those packages to freak
> > * And here we are in the bad ending...
>
> Alternative sum up:
> * People (not just Mikolaj) started using modules, while Koji cannot use 
> modular repos.
>

Addendum: some of us part-time packagers, which depended on these
packages to build our own Java packages don't know how to convert to
modular packaging. I'm still trying to learn in my spare time, but I
don't know where to look and have limited time. It was nearly all the
spare cycles I had just to learn RPM, Fedora RPM packaging policies,
and how to use fedpkg, koji, and bodhi. Now... I'm kinda lost again
and feel like I'm starting over from scratch. I can't be the only one.
I still think a lot of this is being driven by experienced Fedora
packagers, and those involved in composes, but without a lot of regard
to the casual or relatively inexperienced packager. pkgdb was a highly
usable tool for inexperienced packagers, as it was a "one stop shop"
for everything related to your package... but now... it's hard to find
all the tools you need to do packaging.

I have several Java packages that depend on one another, as well as
dependencies now in modular repos. I have no idea where to get
started. Which ones should be in the same module? Should each RPM be
put in separate modules? How do I create convert my packages to
modules? What is the workflow for builds? For updates? Do I still use
fedpkg to submit to koji and bodhi? How will users install my RPMs
now? I feel a bit overwhelmed by all of this... and I'm sure I should
be spending more time trying to figure all this out on my own... but I
really don't know where to start.
___
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: Chromium C++ help needed

[Gary Gatling]

On Tue, Mar 12, 2019 at 7:57 AM Christophe de Dinechin 
wrote:

>
> I tried to compile your preprocessed fragment with both clang or gcc.
> Interestingly:
>
> 1) Without your command-line options, I don’t see the same error.
>
> 2) With your command-line options, I see the error with gcc, but not with
> clang.
>
> So I suspect a compiler bug.
>

Could chromium be built with clang in fedora? Or does it have to be built
with gcc?
___
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: Updating Rawhide vs GPG keys

[Kevin Fenzi]

On 3/11/19 11:45 AM, Fabio Valentini wrote:

> 
> I'm having a similar problem, but with Silverblue / rawhide.
> 
> I installed the system when rawhide was still f30, but now I can't run
> "rpm-ostree upgrade" anymore, due to this error:
> 
> Enabled rpm-md repositories: rawhide
> Updating metadata for 'rawhide'... done
> error: Failed to download gpg key for repo 'rawhide': Curl error (37):
> Couldn't read a file:// file for
> file:///etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-31-x86_64 [Couldn't open file
> /etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-31-x86_64]
> 
> So I'm *VERY* sure that I didn't mess with the system myself (since it's a
> Silverblue installation), but still it's broken due to the missing GPG keys.

Yeah, so the problem is that you were on f30 and then braching happend
and suddenly you were on f31 before you had a chance to pick up the
updated fedora-repos-30 with the 31 key in it.

We need to revamp this entirely, and as luck would have it, we have a plan:

https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/5UVGSBRLX352A4S2CBZ2CGBXPAGQTYKB/

How does this plan work with silverblue? Not sure... could use some
input from them.

kevin



signature.asc
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://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: Updating Rawhide vs GPG keys

[Kevin Fenzi]

On 3/12/19 4:14 AM, Vít Ondruch wrote:
> 
> Dne 11. 03. 19 v 19:29 Kevin Fenzi napsal(a):
>> On 3/11/19 4:31 AM, Vít Ondruch wrote:
>>> Hi,
>>>
>>> Can somebody please enlighten me, how to update Rawhide after branching
>>> and not using --nogpgcheck?
>> Can you expand on the case here?
>>
>> What should happen is:
>>
>> * branching
>> * f30 repos gets the f31 key
> 
> 
> They got the f31 key in -0.4, but the *signed* package with this key
> without subsequent changes to the repositories done in -0.5 is not
> available anywhere.

Thats due to compose issues. A compose completed last night so this
should be there now?

>> * you update your f30-repos
>> * you jump to rawhide and dnf just imports the key.
>>
>> How did you get on rawhide?
>>
>>> It seems that Rawhide keys were added in fedora-repos-30-0.4. So this is
>>> the package which is still "rawhide" package and has "f31" keys. But
>>> this package was not probably signed, because this directory is empty:
>>>
>>> https://kojipkgs.fedoraproject.org/packages/fedora-repos/30/0.4/data/signed/
>> Yeah, no longer shipped packages have their signed packages removed
>> after a while to save space. You just want any newer one there.
>> https://kojipkgs.fedoraproject.org/packages/fedora-repos/30/0.5/data/signed/cfc659b9/
>> for example.
> 
> 
> I did this try 30-0.5 of course, but this is wrong, since installing
> this package makes F30 from my Rawhide, that is not what I want.
> 
> May the the whole problem is, that fedora-gpg-keys has to be updated
> together with fedora-repos?

The problem is that we are calling rawhide two things and have seperate
config for it. Once we call it 'rawhide' instead of a number and use the
same config as other branches I think most of these problems will go away.

> 
> $ LC_ALL=C.UTF-8 sudo dnf update --disablerepo=rawhide
> --enablerepo=updates-testing --release 30
> https://kojipkgs.fedoraproject.org/packages/fedora-repos/30/0.5/data/signed/cfc659b9/noarch/fedora-gpg-keys-30-0.5.noarch.rpm
> Last metadata expiration check: 0:01:12 ago on Tue Mar 12 12:12:22 2019.
> Dependencies resolved.
> 
>  Problem: cannot install both fedora-gpg-keys-30-0.5.noarch and
> fedora-gpg-keys-30-0.2.noarch
>   - package fedora-repos-30-0.2.noarch requires fedora-gpg-keys =
> 30-0.2, but none of the providers can be installed
>   - cannot install the best update candidate for package
> fedora-gpg-keys-30-0.2.noarch
>   - problem with installed package fedora-repos-30-0.2.noarch
> ==
>  Package   
> Architecture 
> Version  
> Repository   Size
> ==
> Skipping packages with conflicts:
> (add '--best --allowerasing' to command line to force their upgrade):
>  fedora-gpg-keys   
> noarch   
> 30-0.5   
> @commandline    102 k
> 
> Transaction Summary
> ==
> Skip  1 Package
> 
> Nothing to do.
> Complete!
> 
> ~~~
> 
> 
> Which is not what you expect?

Try again with --enablerepo=fedora ? You need the base repo not just
updates-testing?

kevin





signature.asc
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://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: Can't push to batched an Fedora 30 update?

[Kevin Fenzi]

On 3/12/19 8:38 AM, Randy Barlow wrote:
> On Mon, 2019-03-11 at 21:55 +0100, Tomasz Torcz wrote:
>>   Hmm, rebulding container on config change? Sounds fishy.
>> Have you tried putting production.ini into ConfigMap?
> 
> It is in a configmap:
> 
> https://infrastructure.fedoraproject.org/cgit/ansible.git/tree/roles/bodhi2/base/templates/configmap.yml#n108
> 
> The reason I rebuilt the container is that I don't have ACLs to access
> OpenShift directly and must interact with it via some Ansible
> playbooks, and the only lever I can pull here that I'm aware of builds
> a new container.

We could add acls to allow application owners to do deploys I think.

Can you open a ticket on it and we can evaluate?

kevin




signature.asc
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://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: Orphaned packages to be retired (Java packages in 3 weeks)

[Mikolaj Izdebski]

On Tue, Mar 12, 2019 at 3:11 PM Jakub Jelen  wrote:
>
> On Tue, 2019-03-12 at 13:43 +0200, Aleksandar Kurtakov wrote:
> > Hmm,
> > https://lists.fedoraproject.org/archives/list/java-de...@lists.fedoraproject.org/thread/MQMRQVENBLDRS67WLNQ7EOCMSDI5WIET/
> > seems that people had a lot of time to act and get involved.
>
> Unfortunately not everyone who happens to maintain a java package is in
> the java SIG and reading the mails there so I think this mail should
> have been sent at least to fedora-devel too, maybe even announce since
> it is touching so many packages (dependencies).

I did send an announcement to devel list several months before to
orphaning packages. The above message from java-devel was linked on
devel list.
See: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/YFUXS7ZX6UDEMEKJWONKFMVDTSBABZID/

> I see that Mikolaj already did a lot of work of moving his packages to
> the modules, so a mail with simple instructions "this is a list of
> things that I did for my packages and if you depend on them, do it
> also", would save many maintainers as me hours of searching the sparse
> modularity documentation.

The approach I used to build my modules should be described in "MBI
(playground 2.0)" on this list. I don't want to spend too much time on
describing the process in very detail - I am actively working on an
improved process that will require less resources.

--
Mikolaj Izdebski
___
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: Orphaned packages to be retired (Java packages in 3 weeks)

[Mikolaj Izdebski]

On Tue, Mar 12, 2019 at 6:20 PM Christopher  wrote:
> Addendum: some of us part-time packagers, which depended on these
> packages to build our own Java packages don't know how to convert to
> modular packaging. I'm still trying to learn in my spare time, but I
> don't know where to look and have limited time. It was nearly all the
> spare cycles I had just to learn RPM, Fedora RPM packaging policies,
> and how to use fedpkg, koji, and bodhi. Now... I'm kinda lost again
> and feel like I'm starting over from scratch. I can't be the only one.
> I still think a lot of this is being driven by experienced Fedora
> packagers, and those involved in composes, but without a lot of regard
> to the casual or relatively inexperienced packager. pkgdb was a highly
> usable tool for inexperienced packagers, as it was a "one stop shop"
> for everything related to your package... but now... it's hard to find
> all the tools you need to do packaging.
>
> I have several Java packages that depend on one another, as well as
> dependencies now in modular repos. I have no idea where to get
> started. Which ones should be in the same module? Should each RPM be
> put in separate modules? How do I create convert my packages to
> modules? What is the workflow for builds? For updates? Do I still use
> fedpkg to submit to koji and bodhi? How will users install my RPMs
> now? I feel a bit overwhelmed by all of this... and I'm sure I should
> be spending more time trying to figure all this out on my own... but I
> really don't know where to start.

With "addon modularity" approach we currently use people shouldn't be
required to convert anything to modules. The idea is that parts of
Fedora can be modularized upon maintainer discretion. This change
should be transparent to users that are not aware of modularity.
Likewise, other Fedora developers should be able to maintain their
packages, even if their dependencies move to modules. That is not
possible without ordinary (non-modular, "ursine") packages being able
to be built against modular content. Unfortunately Fedora developers
(represented by FESCo) decided to forbid use of modules for building
non-modular packages. This was a sad and very disappointing decision
to read about and it was the direct cause that made me make the final
decision to orphan all packages I used to maintain for years.

Personally I think modularity is a great tool that will allow *me* to
reduce the effort needed to maintain packages and at the same time
improve user experience. But your mileage may vary. The effort that
packagers need to make in order to learn the new technology and change
their workflow may greatly outweight any possible gain from
modularity, especially for packagers that maintain fewer packages.
Therefore I discourage developers from moving their packages to
modules if they don't see the benefit for them and their users.
Instead I encourage people to talk about the problem. I hope FESCo
will finally realize how important it is to allow building any package
against modules and change the policy, allowing modules to be used as
build dependencies for non-modular packages.

--
Mikolaj Izdebski
___
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: Orphaned packages to be retired (Java packages in 3 weeks)

[Mikolaj Izdebski]

On Tue, Mar 12, 2019 at 4:42 PM Miroslav Suchý  wrote:
> Alternative sum up:
> * People (not just Mikolaj) started using modules, while Koji cannot use 
> modular repos.

Incorrect. Koji (the software) *can* use modular repos. I know of more
than one installation of Koji that successfully builds non-modular
contents against modules. It's Fedora developers (represented by
elected body of FESCo) that don't want to use modules in Fedoras' Koji
installation.

--
Mikolaj Izdebski
___
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: Orphaned packages to be retired (Java packages in 3 weeks)

[Mikolaj Izdebski]

On Tue, Mar 12, 2019 at 12:17 PM Dominik 'Rathann' Mierzejewski
 wrote:
>
> On Tuesday, 12 March 2019 at 12:02, Mikolaj Izdebski wrote:
> > On Tue, Mar 12, 2019 at 11:49 AM Jakub Jelen  wrote:
> > >
> > > Is there already a way to package the java application as a module or
> > > we will really remove all these package from Fedora?
> >
> > Most of Java packages listed in this thread are already packaged as
> > modules. Their retirement in rawhide won't directly cause their
> > removal from distribution.
>
> Maybe, but it will cause the removal of other packages that depend on
> their regular (non-modular) builds. You are forcing the hands of their
> maintainers before the infrastructure to make modular packages available
> as build dependencies to regular packages is in place to remake their
> packages into modules, let them be retired or pick up your orphans. If
> it were ready, your moving these packages to modules would be a
> non-event for everyone concerned except you. Instead of helping with
> that (or just waiting), you are about to cause the retirement of quite a
> few packages whose maintainers want nothing to do with Modularity.
> That's not excellent.

I am not forcing anyone to do anything. If I followed your thinking
then I colud say that by not adopting orphaned packages you are
forcing others to do the same things you accuse me of forcing people
to.

>
> Regards,
> Dominik
> --
> Fedora   https://getfedora.org  |  RPM Fusion  http://rpmfusion.org
> There should be a science of discontent. People need hard times and
> oppression to develop psychic muscles.
> -- from "Collected Sayings of Muad'Dib" by the Princess Irulan
> ___
> 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
___
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: Orphaned packages to be retired (Java packages in 3 weeks)

[Miro Hrončok]

On 12. 03. 19 22:11, Mikolaj Izdebski wrote:

I hope FESCo
will finally realize how important it is to allow building any package
against modules and change the policy, allowing modules to be used as
build dependencies for non-modular packages.


Oh we do realize. Especially since everything will break if we don't do this.
This was not rejected because we don't want to allow this, but because we were 
not satisfied with the technical solution.


--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://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: Orphaned packages to be retired (Java packages in 3 weeks)

[Randy Barlow]

On Tue, 2019-03-12 at 22:18 +0100, Mikolaj Izdebski wrote:
> It's Fedora developers (represented by
> elected body of FESCo) that don't want to use modules in Fedoras'
> Koji
> installation.

As Miro said in another post, it's not that FESCo doesn't want to use
modules in Koji, it's that we want to make sure that the packager
experience is as good as it was pre-modularity, and in particular that
packagers can build locally as they can today. IIRC, there were
specific concerns about the details of the proposal to use Ursa Major
that were raised at the time.

I do think most of FESCo does want to see the problem solved.


signature.asc
Description: This is a digitally signed message part
___
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: Blocking criteria proposal for F30+: Printing

[Chris Murphy]

On Tue, Mar 12, 2019 at 2:53 AM Zdenek Dohnal  wrote:
>
> IMHO Stephen meant it as driverless 'driver' or IPP everywhere enabled
> printer, since 'generic IPP driver' does not exist.

OK.

> >
> > What supports IPP Everywhere out of the box?
> >
> > Any computer running CUPS 1.5 or later
> I beg to differ that it is not entirely correct.

I got that straight out of the IPP Everywhere FAQ, but the point I did
not state and should have is, Fedora 30 definitely far exceeds the
minimum requirement. That was also the point of pointing out Android
4.4 supports it.


> > Proposal for Fedora 30: If anyone is able to, with reasonable effort,
> > successfully run the agreed test cases to any printer supporting IPP
> > 2.0 or higher, using whatever driver is required, then we don't block.
>
> I would go with 'if printing works on IPP everywhere printer available
> for Fedora QA' (hooray, we have one :) ) 'then do not block'. But it
> seems as technicality...

I'm completely fine with narrowing this to an IPP Everywhere printer
for Fedora 30. From yesterday's QA meeting, I was understanding they
don't have an IPP Everywhere printer, but figured it should be
possible to track down an IPP 2.0+ printer. So yeah if there's an IPP
Everwhere test printer handy, just go with that from the outset.

-- 
Chris Murphy
___
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: Orphaned packages to be retired (Java packages in 3 weeks)

[Christopher]

On Tue, Mar 12, 2019 at 6:03 PM Randy Barlow
 wrote:
> As Miro said in another post, it's not that FESCo doesn't want to use
> modules in Koji, it's that we want to make sure that the packager
> experience is as good as it was pre-modularity, and in particular that
> packagers can build locally as they can today. IIRC, there were
> specific concerns about the details of the proposal to use Ursa Major
> that were raised at the time.

Well, the packager experience I'm expecting in 3 weeks is: "almost all
of my dependencies and BuildRequires are gone; I can't build
anything".
How much worse could it get than that?
___
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

Fedora Rawhide-20190312.n.1 compose check report

[Fedora compose checker]

Missing expected images:

Atomichost qcow2 x86_64
Atomichost raw-xz x86_64

Compose FAILS proposed Rawhide gating check!
9 of 47 required tests failed, 8 results missing
openQA tests matching unsatisfied gating requirements shown with **GATING** 
below
Unsatisfied gating requirements that could not be mapped to openQA tests:
FAILED: compose.cloud.all

Failed openQA tests: 23/141 (x86_64), 4/24 (i386), 1/2 (arm)

ID: 362706  Test: x86_64 Server-dvd-iso server_firewall_default **GATING**
URL: https://openqa.fedoraproject.org/tests/362706
ID: 362708  Test: x86_64 Server-dvd-iso modularity_tests
URL: https://openqa.fedoraproject.org/tests/362708
ID: 362724  Test: x86_64 Workstation-live-iso install_default_upload 
**GATING**
URL: https://openqa.fedoraproject.org/tests/362724
ID: 362725  Test: x86_64 Workstation-live-iso install_default@uefi 
**GATING**
URL: https://openqa.fedoraproject.org/tests/362725
ID: 362744  Test: x86_64 KDE-live-iso install_default_upload **GATING**
URL: https://openqa.fedoraproject.org/tests/362744
ID: 362745  Test: x86_64 KDE-live-iso install_default@uefi **GATING**
URL: https://openqa.fedoraproject.org/tests/362745
ID: 362748  Test: x86_64 KDE-live-iso install_no_user **GATING**
URL: https://openqa.fedoraproject.org/tests/362748
ID: 362757  Test: i386 KDE-live-iso install_default
URL: https://openqa.fedoraproject.org/tests/362757
ID: 362758  Test: arm Minimal-raw_xz-raw.xz 
install_arm_image_deployment_upload
URL: https://openqa.fedoraproject.org/tests/362758
ID: 362797  Test: x86_64 universal install_package_set_kde
URL: https://openqa.fedoraproject.org/tests/362797
ID: 362800  Test: x86_64 universal upgrade_server_64bit
URL: https://openqa.fedoraproject.org/tests/362800
ID: 362801  Test: x86_64 universal upgrade_server_domain_controller
URL: https://openqa.fedoraproject.org/tests/362801
ID: 362802  Test: x86_64 universal upgrade_2_desktop_encrypted_64bit
URL: https://openqa.fedoraproject.org/tests/362802
ID: 362809  Test: x86_64 universal install_anaconda_text **GATING**
URL: https://openqa.fedoraproject.org/tests/362809
ID: 362825  Test: x86_64 universal install_kickstart_firewall_configured 
**GATING**
URL: https://openqa.fedoraproject.org/tests/362825
ID: 362828  Test: x86_64 universal upgrade_minimal_64bit
URL: https://openqa.fedoraproject.org/tests/362828
ID: 362829  Test: x86_64 universal upgrade_desktop_64bit
URL: https://openqa.fedoraproject.org/tests/362829
ID: 362830  Test: x86_64 universal upgrade_realmd_client
URL: https://openqa.fedoraproject.org/tests/362830
ID: 362831  Test: x86_64 universal upgrade_kde_64bit
URL: https://openqa.fedoraproject.org/tests/362831
ID: 362832  Test: x86_64 universal upgrade_desktop_encrypted_64bit
URL: https://openqa.fedoraproject.org/tests/362832
ID: 362833  Test: x86_64 universal upgrade_2_minimal_64bit
URL: https://openqa.fedoraproject.org/tests/362833
ID: 362834  Test: x86_64 universal upgrade_2_desktop_64bit
URL: https://openqa.fedoraproject.org/tests/362834
ID: 362835  Test: x86_64 universal upgrade_2_server_64bit
URL: https://openqa.fedoraproject.org/tests/362835
ID: 362836  Test: x86_64 universal upgrade_2_kde_64bit
URL: https://openqa.fedoraproject.org/tests/362836
ID: 362838  Test: x86_64 universal install_iscsi
URL: https://openqa.fedoraproject.org/tests/362838
ID: 362856  Test: i386 universal upgrade_desktop_32bit
URL: https://openqa.fedoraproject.org/tests/362856
ID: 362857  Test: i386 universal upgrade_2_desktop_32bit
URL: https://openqa.fedoraproject.org/tests/362857
ID: 362858  Test: i386 universal install_package_set_kde
URL: https://openqa.fedoraproject.org/tests/362858

Soft failed openQA tests: 61/141 (x86_64), 18/24 (i386)
(Tests completed, but using a workaround for a known bug)

ID: 362692  Test: x86_64 Server-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/362692
ID: 362693  Test: x86_64 Server-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/362693
ID: 362694  Test: x86_64 Server-dvd-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/362694
ID: 362695  Test: x86_64 Server-dvd-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/362695
ID: 362701  Test: x86_64 Server-dvd-iso install_repository_nfs_variation
URL: https://openqa.fedoraproject.org/tests/362701
ID: 362702  Test: x86_64 Server-dvd-iso install_repository_nfs_graphical
URL: https://openqa.fedoraproject.org/tests/362702
ID: 362711  Test: x86_64 Server-dvd-iso server_realmd_join_kickstart
URL: https://openqa.fedoraproject.org/tests/362711
ID: 362713  Test: x86_64 Server-dvd-iso install_updates_nfs
URL: https://openqa.fedoraproject.org/tests/362713
ID: 362719  Test: i386 Server-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/362719
ID: 362720  Test: i386 Server-dvd-iso install_default
URL: https://openqa.fedo

Re: F31 System-Wide Change proposal: Enable Compiler Security hardening flags by default in G

[Huzaifa Sidhpurwala]

Hi Vit,

On 3/12/19 5:40 PM, Vít Ondruch wrote:
> Will it help to mitigate issues such as:
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=1284684
>
This is related to the following change which was made in Fedora 23:
https://fedoraproject.org/wiki/Changes/Harden_All_Packages.

My proposal does not touch PIE or RELRO at all, but is related to
compiling code with protections which mitigate, format string attacks
and stack-based buffer overflows. It is pretty common to enable these
flags while compiling, its just strange that we dont enable these by
default.

> and mitigate workarounds such as:
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=1543394
> 
> That would be wonderful.
> 
> 
> Also, while OT to this specific change, I would love to have ability to
> have some compiler flags tailored to my environment. E.g. enabled
> optimizations specific to my CPU. That could enable potential of JIT
> compilation in Ruby and possibly everywhere else where compiler is
> involved in installation some extensions from 3rd party repositories.
> 
> 
> Vít
> 
> 
> Dne 11. 03. 19 v 18:56 Ben Cotton napsal(a):
>> https://fedoraproject.org/wiki/Changes/HardenedCompiler
>>
>> == Summary ==
>> By Default enable a few security hardening flags which are used with GCC.
>>
>> == Owner ==
>> * Name: [[User:huzaifas|Huzaifa Sidhpurwala]]
>> * Email: huzai...@redhat.com
>> * Release notes owner: huzai...@redhat.com
>>
>>
>> == Detailed Description ==
>> Currently GCC does not enable any security hardening flags by default.
>> They have to be explicitly enabled by the developers one-by-one.
>> Ubuntu (https://wiki.ubuntu.com/ToolChain/CompilerFlags) however
>> enables them and therefore has a hardened compiler by default. Each of
>> these options can be explicitly disabled if required by the developer
>> via a GCC command line flag.  I am currently proposing the following
>> flags be enabled by default.
>>
>> '''-Wformat -Wformat-security -fstack-protector-strong
>> --param=ssp-buffer-size=4 -D_FORTIFY_SOURCE=2 -O'
>>
>> {| class="wikitable"
>> |-
>> ! No !! Flag !! Use !! How to disable
>> |-
>> | 1 || -Wformat || Check calls to "printf" and "scanf", etc., to make
>> sure that the arguments supplied have types appropriate to the format
>> string specified, and that the conversions specified in the  format
>> string make sense. || -Wno-format
>> |-
>> | 2 || -Wformat-security || If -Wformat is specified, also warn about
>> uses of format functions that represent possible security problems.
>> || -Wno-format should disable this as well
>> |-
>> | 3 || -fstack-protector-strong || Like -fstack-protector but includes
>> additional functions to be protected --- those that have local array
>> definitions, or have references to local frame addresses.
>> || -fno-stack-protector
>> |}
>>
>>
>> == Benefit to Fedora ==
>> We provide better security both for our packages and for
>> applications/programs which users are building.
>>
>> == Scope ==
>> * Proposal owners: Patch gcc to enable these options by default. Patch
>> should be very simple, since the compile/link code isnt actually
>> touched.
>> * Other developers: Developers need to ensure that Fedora package is
>> built and if any build failures they are corrected
>> * Release engineering: [https://pagure.io/releng/issue/8204 #8204]
>> * Policies and guidelines: The policies and guidelines do not need to
>> be updated.
>> * Trademark approval: Not needed for this change
>>
>> == Upgrade/compatibility impact ==
>> None
>>
>> == How To Test ==
>> Run "gcc -Q -v " to check if these flags are enabled by default
>>
>> == User Experience ==
>> Fedora is more secure because the entire distribution is compiled with
>> the correct security technologies enabled. Developers dont have to
>> worry about enabling the right flags when they compile their
>> application in Fedora because the compiler has them enabled by
>> default.
>>
>> == Dependencies ==
>> All packages will be rebuild with new GCC options.
>>
>> == Contingency Plan ==
>> * Contingency mechanism: Roll back the GCC options and use the default ones.
>> * Contingency deadline: Beta Feeze
>> * Blocks release? No
>>
>>
>>
>>
> ___
> 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
> 


-- 
Huzaifa Sidhpurwala / Red Hat Product Security Team
___
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.o

Re: Orphaned packages to be retired (Java packages in 3 weeks)

[Fabio Valentini]

On Tue, Mar 12, 2019, 22:37 Mikolaj Izdebski  wrote:

> On Tue, Mar 12, 2019 at 12:17 PM Dominik 'Rathann' Mierzejewski
>  wrote:
> >
> > On Tuesday, 12 March 2019 at 12:02, Mikolaj Izdebski wrote:
> > > On Tue, Mar 12, 2019 at 11:49 AM Jakub Jelen 
> wrote:
> > > >
> > > > Is there already a way to package the java application as a module or
> > > > we will really remove all these package from Fedora?
> > >
> > > Most of Java packages listed in this thread are already packaged as
> > > modules. Their retirement in rawhide won't directly cause their
> > > removal from distribution.
> >
> > Maybe, but it will cause the removal of other packages that depend on
> > their regular (non-modular) builds. You are forcing the hands of their
> > maintainers before the infrastructure to make modular packages available
> > as build dependencies to regular packages is in place to remake their
> > packages into modules, let them be retired or pick up your orphans. If
> > it were ready, your moving these packages to modules would be a
> > non-event for everyone concerned except you. Instead of helping with
> > that (or just waiting), you are about to cause the retirement of quite a
> > few packages whose maintainers want nothing to do with Modularity.
> > That's not excellent.
>
> I am not forcing anyone to do anything. If I followed your thinking
> then I colud say that by not adopting orphaned packages you are
> forcing others to do the same things you accuse me of forcing people
> to.
>

Still, by making your life a bit easier (by dropping "normal" packages and
moving everything to modules), you make the life of every packager that
depends on those packages harder.

Can you give us a minimal set of packages that is required to make sure
libreoffice etc. aren't caught up in the mass retirement?

I could try to figure that out from the contents of the linked dependency
graph, but you probably already have that information somewhere.

We might want to look for maintainers for that minimal set, at least. (I
think my Package Stewardship SIG idea is showing its merits here ...)

Fabio


> >
> > Regards,
> > Dominik
> > --
> > Fedora   https://getfedora.org  |  RPM Fusion  http://rpmfusion.org
> > There should be a science of discontent. People need hard times and
> > oppression to develop psychic muscles.
> > -- from "Collected Sayings of Muad'Dib" by the Princess Irulan
> > ___
> > 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
> ___
> 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
>
___
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: Orphaned packages to be retired (Java packages in 3 weeks)

[Alexander Bokovoy]

On ke, 13 maalis 2019, Fabio Valentini wrote:

On Tue, Mar 12, 2019, 22:37 Mikolaj Izdebski  wrote:


On Tue, Mar 12, 2019 at 12:17 PM Dominik 'Rathann' Mierzejewski
 wrote:
>
> On Tuesday, 12 March 2019 at 12:02, Mikolaj Izdebski wrote:
> > On Tue, Mar 12, 2019 at 11:49 AM Jakub Jelen 
wrote:
> > >
> > > Is there already a way to package the java application as a module or
> > > we will really remove all these package from Fedora?
> >
> > Most of Java packages listed in this thread are already packaged as
> > modules. Their retirement in rawhide won't directly cause their
> > removal from distribution.
>
> Maybe, but it will cause the removal of other packages that depend on
> their regular (non-modular) builds. You are forcing the hands of their
> maintainers before the infrastructure to make modular packages available
> as build dependencies to regular packages is in place to remake their
> packages into modules, let them be retired or pick up your orphans. If
> it were ready, your moving these packages to modules would be a
> non-event for everyone concerned except you. Instead of helping with
> that (or just waiting), you are about to cause the retirement of quite a
> few packages whose maintainers want nothing to do with Modularity.
> That's not excellent.

I am not forcing anyone to do anything. If I followed your thinking
then I colud say that by not adopting orphaned packages you are
forcing others to do the same things you accuse me of forcing people
to.



Still, by making your life a bit easier (by dropping "normal" packages and
moving everything to modules), you make the life of every packager that
depends on those packages harder.

Can you give us a minimal set of packages that is required to make sure
libreoffice etc. aren't caught up in the mass retirement?

I could try to figure that out from the contents of the linked dependency
graph, but you probably already have that information somewhere.

We might want to look for maintainers for that minimal set, at least. (I
think my Package Stewardship SIG idea is showing its merits here ...)

Another, pragmatic, approach would be to actually postpone or revert
orphaning process for all those packages now that there is understanding
that FESCO is not opposed and is merely looking for a satisfying
technical solution. I've been told by contyk and others that it is
closer to reality now.

--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland
___
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