Fedora 27-20170828.n.0 compose check report

[Fedora compose checker]

Missing expected images:

Cloud_base qcow2 x86_64
Atomic qcow2 x86_64
Workstation live i386
Cloud_base raw-xz x86_64
Server boot i386
Atomic raw-xz x86_64
Kde live i386

Failed openQA tests: 71/126 (x86_64), 16/18 (i386), 1/2 (arm)

Old failures (same test failed in 27-20170827.n.0):

ID: 135607  Test: x86_64 Server-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/135607
ID: 135608  Test: x86_64 Server-dvd-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/135608
ID: 135609  Test: x86_64 Server-dvd-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/135609
ID: 135616  Test: x86_64 Server-dvd-iso install_repository_nfs_variation
URL: https://openqa.fedoraproject.org/tests/135616
ID: 135617  Test: x86_64 Server-dvd-iso install_repository_nfs_graphical
URL: https://openqa.fedoraproject.org/tests/135617
ID: 135626  Test: x86_64 Server-dvd-iso install_updates_nfs
URL: https://openqa.fedoraproject.org/tests/135626
ID: 135628  Test: i386 Server-dvd-iso install_default
URL: https://openqa.fedoraproject.org/tests/135628
ID: 135630  Test: x86_64 Everything-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/135630
ID: 135631  Test: x86_64 Workstation-live-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/135631
ID: 135632  Test: x86_64 Workstation-live-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/135632
ID: 135633  Test: x86_64 Workstation-live-iso install_no_user
URL: https://openqa.fedoraproject.org/tests/135633
ID: 135646  Test: x86_64 Workstation-boot-iso memory_check@uefi
URL: https://openqa.fedoraproject.org/tests/135646
ID: 135647  Test: x86_64 Workstation-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/135647
ID: 135648  Test: x86_64 KDE-live-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/135648
ID: 135649  Test: x86_64 KDE-live-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/135649
ID: 135650  Test: x86_64 KDE-live-iso install_no_user
URL: https://openqa.fedoraproject.org/tests/135650
ID: 135662  Test: arm Minimal-raw_xz-raw.xz base_services_start_arm
URL: https://openqa.fedoraproject.org/tests/135662
ID: 135663  Test: x86_64 universal install_package_set_minimal
URL: https://openqa.fedoraproject.org/tests/135663
ID: 135664  Test: x86_64 universal install_anaconda_text
URL: https://openqa.fedoraproject.org/tests/135664
ID: 135665  Test: x86_64 universal upgrade_desktop_64bit
URL: https://openqa.fedoraproject.org/tests/135665
ID: 135666  Test: x86_64 universal upgrade_server_64bit
URL: https://openqa.fedoraproject.org/tests/135666
ID: 135667  Test: x86_64 universal upgrade_server_domain_controller
URL: https://openqa.fedoraproject.org/tests/135667
ID: 135669  Test: x86_64 universal upgrade_kde_64bit
URL: https://openqa.fedoraproject.org/tests/135669
ID: 135670  Test: x86_64 universal upgrade_desktop_encrypted_64bit
URL: https://openqa.fedoraproject.org/tests/135670
ID: 135671  Test: x86_64 universal upgrade_2_minimal_64bit
URL: https://openqa.fedoraproject.org/tests/135671
ID: 135672  Test: x86_64 universal upgrade_2_desktop_64bit
URL: https://openqa.fedoraproject.org/tests/135672
ID: 135673  Test: x86_64 universal upgrade_2_server_64bit
URL: https://openqa.fedoraproject.org/tests/135673
ID: 135674  Test: x86_64 universal upgrade_2_kde_64bit
URL: https://openqa.fedoraproject.org/tests/135674
ID: 135675  Test: x86_64 universal upgrade_2_desktop_encrypted_64bit
URL: https://openqa.fedoraproject.org/tests/135675
ID: 135676  Test: x86_64 universal install_updates_img_local
URL: https://openqa.fedoraproject.org/tests/135676
ID: 135677  Test: x86_64 universal install_shrink_ext4
URL: https://openqa.fedoraproject.org/tests/135677
ID: 135678  Test: x86_64 universal install_shrink_ntfs
URL: https://openqa.fedoraproject.org/tests/135678
ID: 135687  Test: x86_64 universal install_delete_pata
URL: https://openqa.fedoraproject.org/tests/135687
ID: 135688  Test: x86_64 universal install_delete_pata@uefi
URL: https://openqa.fedoraproject.org/tests/135688
ID: 135689  Test: x86_64 universal install_sata
URL: https://openqa.fedoraproject.org/tests/135689
ID: 135690  Test: x86_64 universal install_sata@uefi
URL: https://openqa.fedoraproject.org/tests/135690
ID: 135692  Test: x86_64 universal install_scsi_updates_img
URL: https://openqa.fedoraproject.org/tests/135692
ID: 135695  Test: x86_64 universal install_multi
URL: https://openqa.fedoraproject.org/tests/135695
ID: 135696  Test: x86_64 universal install_multi@uefi
URL: https://openqa.fedoraproject.org/tests/135696
ID: 135697  Test: x86_64 universal install_simple_encrypted
URL: https://openqa.fedoraproject.org/tests/135697
ID: 135698  Test: x86_64 universal install_simple_free_space
URL: https://openqa.fedoraproject.

Re: Urgent attention required; ImageMagick update breakage

[Michael Cronenworth]

Rebuild status:
* All F25/F26 packages have been rebuilt against ImageMagick 6.9.9.9
* Most of the F27+ packages have been rebuilt with the following exceptions:
  - cuneiform
FTBFS since Fedora 23, last upstream release is from 2011
  - imageinfo
Requires porting, upstream is alive. I may come back and fix this later. CC'ing 
maintainer.

  - perl-Image-SubImageFind
Requires porting, upstream is dead
  - psiconv
Requires porting, upstream is dead
  - q
Obsolete back in 2008, replaced by "Pure" language... which is not in Fedora
  - rubygem-rmagick
Requires porting, upstream is alive, but not interested. I'll have to come back 
to this one. CC'ing maintainer.


The rebuilt packages are using a direct support style patch and not a comprehensive 
support patch. I'll be making comprehensive patches when I have time and shipping 
them upstream. If anyone wants to create a patch before I do please feel free. Just 
link the upstream git commit or report with the patch.


Thanks,
Michael

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

Fedora Rawhide-20170828.n.0 compose check report

[Fedora compose checker]

Missing expected images:

Cloud_base qcow2 x86_64
Workstation live i386
Cloud_base raw-xz x86_64
Server boot i386
Kde live i386

Failed openQA tests: 75/137 (x86_64), 16/18 (i386), 1/2 (arm)

New failures (same test did not fail in Rawhide-20170826.n.0):

ID: 135545  Test: x86_64 universal install_kickstart_user_creation
URL: https://openqa.fedoraproject.org/tests/135545

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

ID: 135450  Test: x86_64 Server-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/135450
ID: 135451  Test: x86_64 Server-dvd-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/135451
ID: 135452  Test: x86_64 Server-dvd-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/135452
ID: 135459  Test: x86_64 Server-dvd-iso install_repository_nfs_variation
URL: https://openqa.fedoraproject.org/tests/135459
ID: 135460  Test: x86_64 Server-dvd-iso install_repository_nfs_graphical
URL: https://openqa.fedoraproject.org/tests/135460
ID: 135469  Test: x86_64 Server-dvd-iso install_updates_nfs
URL: https://openqa.fedoraproject.org/tests/135469
ID: 135471  Test: i386 Server-dvd-iso install_default
URL: https://openqa.fedoraproject.org/tests/135471
ID: 135473  Test: x86_64 Everything-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/135473
ID: 135474  Test: x86_64 Workstation-live-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/135474
ID: 135475  Test: x86_64 Workstation-live-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/135475
ID: 135476  Test: x86_64 Workstation-live-iso install_no_user
URL: https://openqa.fedoraproject.org/tests/135476
ID: 135489  Test: x86_64 Workstation-boot-iso memory_check@uefi
URL: https://openqa.fedoraproject.org/tests/135489
ID: 135490  Test: x86_64 Workstation-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/135490
ID: 135491  Test: x86_64 KDE-live-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/135491
ID: 135492  Test: x86_64 KDE-live-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/135492
ID: 135493  Test: x86_64 KDE-live-iso install_no_user
URL: https://openqa.fedoraproject.org/tests/135493
ID: 135504  Test: arm Minimal-raw_xz-raw.xz 
install_arm_image_deployment_upload
URL: https://openqa.fedoraproject.org/tests/135504
ID: 135508  Test: x86_64 Workstation-dvd_ostree-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/135508
ID: 135509  Test: x86_64 Workstation-dvd_ostree-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/135509
ID: 135510  Test: x86_64 Workstation-dvd_ostree-iso install_no_user
URL: https://openqa.fedoraproject.org/tests/135510
ID: 135517  Test: x86_64 universal install_package_set_minimal
URL: https://openqa.fedoraproject.org/tests/135517
ID: 135518  Test: x86_64 universal install_anaconda_text
URL: https://openqa.fedoraproject.org/tests/135518
ID: 135519  Test: x86_64 universal upgrade_desktop_64bit
URL: https://openqa.fedoraproject.org/tests/135519
ID: 135520  Test: x86_64 universal upgrade_server_64bit
URL: https://openqa.fedoraproject.org/tests/135520
ID: 135521  Test: x86_64 universal upgrade_server_domain_controller
URL: https://openqa.fedoraproject.org/tests/135521
ID: 135523  Test: x86_64 universal upgrade_kde_64bit
URL: https://openqa.fedoraproject.org/tests/135523
ID: 135524  Test: x86_64 universal upgrade_desktop_encrypted_64bit
URL: https://openqa.fedoraproject.org/tests/135524
ID: 135525  Test: x86_64 universal upgrade_2_minimal_64bit
URL: https://openqa.fedoraproject.org/tests/135525
ID: 135526  Test: x86_64 universal upgrade_2_desktop_64bit
URL: https://openqa.fedoraproject.org/tests/135526
ID: 135527  Test: x86_64 universal upgrade_2_server_64bit
URL: https://openqa.fedoraproject.org/tests/135527
ID: 135528  Test: x86_64 universal upgrade_2_kde_64bit
URL: https://openqa.fedoraproject.org/tests/135528
ID: 135529  Test: x86_64 universal upgrade_2_desktop_encrypted_64bit
URL: https://openqa.fedoraproject.org/tests/135529
ID: 135530  Test: x86_64 universal install_updates_img_local
URL: https://openqa.fedoraproject.org/tests/135530
ID: 135531  Test: x86_64 universal install_shrink_ext4
URL: https://openqa.fedoraproject.org/tests/135531
ID: 135532  Test: x86_64 universal install_shrink_ntfs
URL: https://openqa.fedoraproject.org/tests/135532
ID: 135541  Test: x86_64 universal install_delete_pata
URL: https://openqa.fedoraproject.org/tests/135541
ID: 135542  Test: x86_64 universal install_delete_pata@uefi
URL: https://openqa.fedoraproject.org/tests/135542
ID: 135543  Test: x86_64 universal install_sata
URL: https://openqa.fedoraproject.org/tests/135543
ID: 135544  Test: x86_64 universal install_sata@uefi
URL: https://openqa.fedoraproject.org/tests/1355

Re: [modularity] Modules and AppStream

[Kevin Kofler]

Matthew Miller wrote:
> Sure, that's fair. Here's the goal: users will have more options
> without exponentially increasing work for packagers and
> distro-creators.

The exponential number of combinations will still exist, it will just be out 
of our, or really anybody's, control. It is impossible to test the 
exponential number of module version combinations.

And as evidenced in the next point, due to module version conflicts, users 
can actually end up with FEWER options than before.

And the tighter you set the module version requirements in inter-module 
dependencies to work around the first issue, the worse the second issue 
becomes.

>> That destroys the possibility to install all Fedora packages on all
>> Fedora spins, which the shared Everything repository guaranteed. With
>> Modularity fully implemented, you can end up being unable to install KDE
>> Plasma on the GNOME Workstation or the other way round (at least without
>> resorting to containers) because the desktops depend on conflicting
>> versions of some library module. How is that an improvement?
> 
> That scenario clearly isn't an improvement, but it's also an edge case.

I do not see installing multiple desktops as an edge case. Sure, it might 
not be the common case, but it is still very frequent. It is often desired 
as soon as the computer has more than one user, and even a single user may 
want to try out another desktop without uninstalling his/her primary desktop 
environment.

> Anecdotally, I see "I want KDE without all this GNOME stuff" more than
> I see "I want all these desktops installed at once".

Yet, Fedora does not actually provide that, only Kannolo does. :-)

> But, in any case, yes, that's a tradeoff. The upside is that we'll be
> able to scale up in ways we can't otherwise.

Such as?

> And it means that desktops _do_ have the flexibility to have conflicting
> libraries where that is beneficial.

But that is a major disservice to our users. There is a reason that such a 
solution was ruled out for the Fedora 15 NetworkManager conflict. 
(Unfortunately, the solution that was implemented also sucked. The late NM 
0.9 change should have been rejected instead.)

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

[Fedocal] Reminder meeting : Modularity Office Hours

[nils]

Dear all,

You are kindly invited to the meeting:
   Modularity Office Hours on 2017-08-29 from 10:00:00 to 11:00:00 US/Eastern
   At https://meet.jit.si/fedora-modularity

The meeting will be about:
This is where you ask the Fedora Modularity Team questions (and we try to 
answer them)!

Join us on [IRC](irc://chat.freenode.net/#fedora-modularity): 
#fedora-modularity on [FreeNode](https://freenode.net)


Source: https://apps.fedoraproject.org/calendar/meeting/5910/

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

Re: No i686 kernel: Can we require SSE2 for i686?

[Stephen John Smoogen]

On 28 August 2017 at 11:00, Ralf Corsepius  wrote:
> On 07/12/2017 03:44 PM, Zbigniew Jędrzejewski-Szmek wrote:
>>
>> On Wed, Jul 12, 2017 at 08:44:02AM -0400, Matthew Miller wrote:
>>>
>>> On Wed, Jul 12, 2017 at 01:20:58PM +0200, Ralf Corsepius wrote:
>
> The fact that i686 kernels continue to work in general is basically
> luck.

 You probably will deny this, but in practice it has been so for many
 years, because the i686 has dropped out of RHAT's business interest.
>>>
>>>
>>> I don't think this is unreasonable. It is easy for us to support
>>> architectures that a company is paying people to support. It is hard
>>> for us to support architectures that are not getting that that kind of
>>> support. As noted in this thread, this isn't just Red Hat -- it is true
>>> of upstream i686 as well. No one is really interested in this. I
>>> guarantee you that if some non-Red Hat person showed up and said "Hey,
>>> I'm here to work on i686 N hours per week", we would say "awesome", not
>>> "Red Hat doesn't care".
>>
>>
>> Would it be possible to make this a Prioritized Bug?
>> It seems to be a classic case of "affects a lot of people, nobody seems
>> to want to take interest".
>
>
> Agreed, however I feel it's a classic case of "affects a lot of people, but
> RHAT doesn't allow anybody to take action".
>
> That said, I do own and use several i686, but have learnt it's fruitless to
> report bugs, because RHAT ignores them and because RHAT does not allow the
> community to get involved.
>
> Ralf
>
> PS: Yes, your impression is right. I feel very grumpy about all this.
>

I am looking for anyone who would be willing to take over the x86_32
group. If you would like to do that, please join the mailing list and
post what you want done.

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



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

[SO-NAME BUMP] Updating jsoncpp on Rawhide and fc27

[Björn 'besser82' Esser]

Hello folks,

I'm planning to update jsoncpp on Rawhide and fc27 during the next 
days.  After the builds have landed, I'll take care of rebuilding all 
consumers against the new so name.  Since the API / ABI has no publicly 
consumed symbols removed, I don't expect any real problems.


Cheers,
  Björn
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Mysterious build, perhaps tagged to wrong release?

[Marian Csontos]

On 08/26/2017 08:16 PM, Sandro Mani wrote:

Hi

I've got an odd situation with mingw-qt5-qtbase on f26: in git, I have 
version 5.7.1, however there is a mingw-qt5-qtbase-5.8.0-3.fc26 in koji 
[2] which I cannot understand where it came from, considering also that 
other 5.7.1-x versions have been built since. I'm now in the situation 
where I cannot push an update [3] to stable since


"Cannot submit mingw-qt5-qtbase ('0', '5.7.1', '5.fc26') to stable since 
it is older than ('0', '5.8.0', '3.fc26')"


The update was however successfully pushed to testing a couple of days ago.

Any idea what's going on? Was the mingw-qt5-qtbase-5.8.0-3.fc26 build 
erroneously tagget to the wrong release (i.e. f26 instead of what was 
master at the time?


Thanks
Sandro


[1] 
https://src.fedoraproject.org/rpms/mingw-qt5-qtbase/blob/f26/f/mingw-qt5-qtbase.spec 


[2] https://koji.fedoraproject.org/koji/packageinfo?packageID=15392
[3] https://bodhi.fedoraproject.org/updates/FEDORA-2017-d5735b89e6
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org


This is caused by:

https://pagure.io/releng/issue/6807

I gave these updates -1 karma, but the incorrectly tagged packages were 
removed and updates went live after removing some affected packages and 
getting enough karma. Seems not all affected packages were removed.


It was fixed here:

https://pagure.io/fork/mohanboddu/releng/c/014e14f98f36bbac87a2ee15962c3e42ecfe72f4

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

Re: [modularity] Modules and AppStream

[nicolas . mailhot]

De: "Kevin Kofler" 

Matthew Miller wrote:

>> And, it will also allow those of us working on assembling spins and more
>> options — for example, we can have different streams for Atomic without
>> needing to actually duplicate every package. (And we could do the same for
>> KDE or whatever other artifacts would benefit from that, if we want.)

>That destroys the possibility to install all Fedora packages on all Fedora 
>spins, which the shared Everything repository guaranteed.

Indeed :(

The initiative posits it is technically possible to define clear-cut autonomous 
modules, it is human-effective to do so and that the result will satisfy users. 
It underestimates the huge end-user value of an integrated unified repository, 
that drastically reduces the human cost of using Fedora.

The technical possibility seems dubious to me given that an awful lot of the 
software ecosystem Fedora ships is developed in a bazaar interconnected style. 
Case in point the various attempts to make perl optional — it's always rising 
back somewhere. However Fedora and Red Hat are good at technical stuff, throw 
enough devs at it it and some sort of technical solution to identify and manage 
possible module boundaries will probably emerge.

The human effectiveness seems harder. Fedora was never this ambitious before. 
Spins are polite abstractions that are mere starting points (by design). I 
doubt any big deployments of "pure" Fedora spins without added packages exist. 
How many market studies do one need to define sensible functional module 
boundaries? What will be the shelf life of the result? How many people need to 
work on creating and maintaining those boundaries? Is the community interested 
on working on this or will it have to be shouldered by the generous sponsor, 
making Fedora less a community organisation? A general-purpose OS is much more 
complex than the simplistic single-purpose leaf GUI apps shipped on 
smartphones. I happily use rygel on a headless box to stream music to various 
appliances, making it a dlna server installation even though it is created for 
desktops. Plus the whole additional module definition step introduces friction 
and delay in a fast-moving software distribution.

Finally, do the users ask for this modularity? Will they like the result? The 
huge selling point of live images some years ago was that one could install 
packages without being constrained by the predefined selection. Customer 
feedback on RHEL split repositories and multiplication of additional channels 
was dire enough Red Hat had to nix them. I can see the benefit from a 
monetization point of view, modules are a great way to construct textbook 
market segmentation. However at this stage the benefits of modularity for end 
users seem less clear to me. Certainly not clear, concrete and immediate enough 
to make huge and inflexible blobs more palatable than modular packages. 

I guess Modularity needs to progress to have some answers, but as an experiment 
it seems awfully risky to me.

>With Modularity 
>fully implemented, you can end up being unable to install KDE Plasma on the 
>GNOME Workstation or the other way round (at least without resorting to 
>containers) because the desktops depend on conflicting versions of some 
>library module. How is that an improvement?

The problem is not containerization versus parallel installation. Because, 
let's be honest, network, storage and hardware will absorb it if not now then 
in the next years. And inter-container communication can probably be solved 
with enough technical investment. Sure, this investment may seem huge and 
unnecessary, but that's for the people doing the work to judge. And I hope they 
won't forget the dire reputation for slowness Solaris acquired after years of 
priorizing convenience over performance (SUN played with zones before us!).

The problem is that different versions of the same components will have 
slightly different behaviour and configuration rules. The amount of divergence 
users are willing to tolerate on a single system is way way lower that what can 
be technically installed using technical means such as containers or parallel 
install. That will drastically limit the imaginary savings of deferring porting 
apps to the same deps. Unified theming history show it is not so easy to hide 
behaviour differences even for simple stupid stuff such as colour values.
 
Best regards,

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

Re: I need your reviews

[Robert-André Mauchin]

Le lundi 28 août 2017 à 15:49:54 (+0200), Peter Lemenkov a écrit :
> Hello Robert-André,
> Could you please review these three relatively simple packages in return?
> 
> * https://bugzilla.redhat.com/1484835 - erlang-stdlib2
> * https://bugzilla.redhat.com/1484843 - erlang-chronos
> * https://bugzilla.redhat.com/1484846 - erlang-hyper
> 

Thank you so much for your reviews! I've done yours, if you need anything
else, don't hesitate.

Best regards,

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

Re: No i686 kernel: Can we require SSE2 for i686?

[Ralf Corsepius]

On 08/28/2017 04:35 PM, Florian Weimer wrote:


https://bugzilla.redhat.com/show_bug.cgi?id=1482798
(Bug 1482798 - Illegal instruction in SHA1_Update() when used by chronyd)


That's definitely a bug for F27.

nss-softok is broken in similar ways on fedora-26-i686

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

Re: No i686 kernel: Can we require SSE2 for i686?

[Ralf Corsepius]

On 07/12/2017 03:44 PM, Zbigniew Jędrzejewski-Szmek wrote:

On Wed, Jul 12, 2017 at 08:44:02AM -0400, Matthew Miller wrote:

On Wed, Jul 12, 2017 at 01:20:58PM +0200, Ralf Corsepius wrote:

The fact that i686 kernels continue to work in general is basically luck.

You probably will deny this, but in practice it has been so for many
years, because the i686 has dropped out of RHAT's business interest.


I don't think this is unreasonable. It is easy for us to support
architectures that a company is paying people to support. It is hard
for us to support architectures that are not getting that that kind of
support. As noted in this thread, this isn't just Red Hat -- it is true
of upstream i686 as well. No one is really interested in this. I
guarantee you that if some non-Red Hat person showed up and said "Hey,
I'm here to work on i686 N hours per week", we would say "awesome", not
"Red Hat doesn't care".


Would it be possible to make this a Prioritized Bug?
It seems to be a classic case of "affects a lot of people, nobody seems
to want to take interest".


Agreed, however I feel it's a classic case of "affects a lot of people, 
but RHAT doesn't allow anybody to take action".


That said, I do own and use several i686, but have learnt it's fruitless 
to report bugs, because RHAT ignores them and because RHAT does not 
allow the community to get involved.


Ralf

PS: Yes, your impression is right. I feel very grumpy about all this.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: [modularity] Modules and AppStream

[Petr Pisar]

On 2017-08-28, Matthew Miller  wrote:
>> > Modularity will allowing *us* at the packaging end to separate source 
>> > and spec lifecycle from binary and artifact lifecycle.
>> That, by itself, is not a goal. It is a way to achieve an unspecified goal.
>
> Sure, that's fair. Here's the goal: users will have more options
> without exponentially increasing work for packagers and
> distro-creators.
>
This is not currently true. Actually the reality is opposite.

If a module needs a build-time dependency, the packager must add it
including all recursive dependencies into the module's modulemd file. If
another packager wants to create another module with the same build-time
dependency, he needs to do it again. So now you have to maintain the
same thing twice.

Pure theoratically that could have been resolved by creating a new
module with the common dependency, but that means we would have to
create a module for every package.

And that's very labor intensive. And it cannot be automated because
Fedora packages constitute a graph. Not a tree. A packager must come and cut
build cycles or optional features to make the dependency chain sane and
buildable. And such a common dependency module cannot satisfy everybody
because it will be missing the required optional features that were
removed.

Traditional Fedora manages the enormous work of maintanance by
distributing it among packagers so that everybody cares only about her
packages. If we want to create modular Fedora comparable in feature sets
with the traditional Fedora, we must levarage this technique.

Each source package must declare its dependencies and set of optional
features so that it will be possible to compute minimal dependency tree
for a given package programatically.

RPM cannot do it now. We only have build conditions (%bcond_without)
that cannot be handled programatcially. We must change it, oterwise
modular Fedora is doomed.

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

Re: No i686 kernel: Can we require SSE2 for i686?

[Florian Weimer]

On 08/28/2017 04:11 PM, Tomasz Torcz wrote:
> On Tue, Jul 11, 2017 at 10:26:03PM +0200, Florian Weimer wrote:
>> I ran into this unannounced change:
>>
>>   https://fedoraproject.org/wiki/Changes/Stop_Building_i686_Kernels
>>
>> If this is accepted, all x86 hardware on which Fedora can run will
>> support SSE2, and we should reflect that in the i686 build flags.
>>
>   So, what was the conclusion from this thread?

No conclusion yet.  There's a Fesco ticket you can track:

  

Once the kernel question has been settled, we can revisit the matter of
compilation flags for F28.

> https://bugzilla.redhat.com/show_bug.cgi?id=1482798
> (Bug 1482798 - Illegal instruction in SHA1_Update() when used by chronyd)

That's definitely a bug for F27.

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

Re: [modularity] Modules and AppStream

[Matthew Miller]

On Sat, Aug 26, 2017 at 04:04:27AM +0200, Kevin Kofler wrote:
> You could actually just have skipped the October-November release as you did 
> during the F21 cycle, leading to a single 9-month cycle, then back to 6 
> months. I think a 9-month cycle would be much more realistic than a 3-month 
> cycle to fix a 3-month offset from the desired release dates.

Yes, possibly; let's see how this goes in practice. I think in the
future we may want to officially say that if a release is delayed into
July or January, we skip the next one.

> > On the one hand, the new https://src.fedoraproject.org/ site is 
> > awesome.
> Is it really? The Pagure git browser is still missing as basic features as 
> browsing the history of individual files or directories, something I already 

That'd be a nice feature and is important _in general_, but since for
Fedora RPMs and containers the repo changes are _mostly_ to one control
file (spec or dockerfile), with other files generally replaced in their
entirety if not just added or removed, I don't think it's a huge
shortcoming for this use case.

[some stuff snipped here where I think we just disagree and that's
okay]



> > and reuse of @, or simply a different syntax). In any case, this
> > feedback _is_ important and _is_ listened to.
> 
> I, too, hope that this will be addressed.
> 
> What I also hope is that there will be a way (by uninstalling a plugin RPM 
> or by setting some dnf.conf option) to avoid retrieving the module metadata 
> entirely. (In fact, I'd hope that that'll be the default on the traditional 
> Spins!)

At least in the short term, yeah, modularity-using release artifacts
(spins, editions, containers, whatever) will use that and traditional
ones will not.



> > Modularity will allowing *us* at the packaging end to separate source 
> > and spec lifecycle from binary and artifact lifecycle.
> That, by itself, is not a goal. It is a way to achieve an unspecified goal.

Sure, that's fair. Here's the goal: users will have more options
without exponentially increasing work for packagers and
distro-creators.



> That destroys the possibility to install all Fedora packages on all Fedora 
> spins, which the shared Everything repository guaranteed. With Modularity 
> fully implemented, you can end up being unable to install KDE Plasma on the 
> GNOME Workstation or the other way round (at least without resorting to 
> containers) because the desktops depend on conflicting versions of some 
> library module. How is that an improvement?

That scenario clearly isn't an improvement, but it's also an edge case.
Anecdotally, I see "I want KDE without all this GNOME stuff" more than
I see "I want all these desktops installed at once". It's _nice_ to be
able to do that, but I don't think _vital_, as long a there's an easy
way to switch if you want to. Or, it may be that "resorting to
containers" solves the problem nicely anyway.

But, in any case, yes, that's a tradeoff. The upside is that we'll be
able to scale up in ways we can't otherwise. And it means that desktops
_do_ have the flexibility to have conflicting libraries where that is
beneficial.


> The arbitrary branching is what leads to users having to track a different 
> end of life date for, in the worst case, every single package. If Modularity 
> is a success, users will have installed dozens of modules. If each of them 
> comes with a different branch EOL, how does the user know when it's time to 
> upgrade to a supported branch? (Or else, if you do the upgrade 
> automatically, how do you ensure it does not break things? We have releases 
> rather than a rolling release for a reason!)

This is a case of "just because we can do anything doesn't mean we
should do everything". See my earlier proposal on guidelines for EOL
dates (in short: let's make sure they always line up with traditional
release EOLs to simplify the problem).




-- 
Matthew Miller

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

Re: [modularity] Modules and AppStream

[Matthew Miller]

On Fri, Aug 25, 2017 at 07:26:20PM -0400, Ben Rosser wrote:
> I have similar concerns and frustrations as Neal does, I think.
> 
> I first want to comment that I appreciate your willingness to engage
> people (like Neal, and like myself) who seem frustrated with the
> future direction of Fedora. And also, I think modularity-- as you
> described it above-- is a very admirable goal. I have plenty of
> packages that do not really need separate versions per each Fedora
> release, and it would be nice to only need to maintain one branch for
> them.
> 
> My fear is that Fedora, in the process of rolling out modularity, will
> get halfway to the idealized goal and then discover that it's not
> possible to go the rest of the way (for whatever reason), but also
> that it's not possible to easily roll back to a non-modular world, and
> we'll be stuck. Even if we don't encounter some critical design flaw,
> I could certainly see us learning that it's far more complex to
> maintain modules in practice than we think, or perhaps that it
> ultimately makes things more complicated for users rather than less.

Thanks Ben. You're right that we need to make sure we have good
contingency plans every step of the way. There's some irony here
because (see thread on this from a little bit ago) _successful_
modularity will give us a mechanism for backing things out that we've
never had before. But we have to get there. :)

-- 
Matthew Miller

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

Re: No i686 kernel: Can we require SSE2 for i686?

[Tomasz Torcz]

On Tue, Jul 11, 2017 at 10:26:03PM +0200, Florian Weimer wrote:
> I ran into this unannounced change:
> 
>   https://fedoraproject.org/wiki/Changes/Stop_Building_i686_Kernels
> 
> If this is accepted, all x86 hardware on which Fedora can run will
> support SSE2, and we should reflect that in the i686 build flags.
> 

  So, what was the conclusion from this thread?  Because current rawhide
seem to require SSE2 on i686, yet I saw no announcement. See:

https://bugzilla.redhat.com/show_bug.cgi?id=1482798
(Bug 1482798 - Illegal instruction in SHA1_Update() when used by chronyd)

-- 
Tomasz Torcz   "Never underestimate the bandwidth of a station
xmpp: zdzich...@chrome.plwagon filled with backup tapes." -- Jim Gray
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: I need your reviews

[Peter Lemenkov]

Hello Robert-André,
Could you please review these three relatively simple packages in return?

* https://bugzilla.redhat.com/1484835 - erlang-stdlib2
* https://bugzilla.redhat.com/1484843 - erlang-chronos
* https://bugzilla.redhat.com/1484846 - erlang-hyper

2017-08-17 18:45 GMT+02:00 Robert-André Mauchin :
> Hello,
>
> After reviewing near 50 packages recently, I'd really like if anyone
> could also review a few of my packages which are sitting around.
> Of course, I'm open to review swaps, so if you have an old package that
> have been waiting for a review too, please contact me.
>
> Currently, I have waiting:
>  - intel-hybrid-driver: This enables VP9 decoding ability on Skylake/Kabylake
> https://bugzilla.redhat.com/show_bug.cgi?id=1475962
>  - qdirstat: a clone of k4dirstat written with Qt5
>  https://bugzilla.redhat.com/show_bug.cgi?id=1476201
>  - A whole bunch of Golang library needed for packaging rclone. They are
>all generated by the gofed utility so they should be straightforward
>to review:
>  - golang-github-jlaffaye-ftp - A FTP client package for Go
>https://bugzilla.redhat.com/show_bug.cgi?id=1475817
>  - golang-github-golang-sync - Go concurrency primitives
>https://bugzilla.redhat.com/show_bug.cgi?id=1475872
>  - golang-github-billziss-gh-cgofuse - Cross-platform FUSE library for Go
>https://bugzilla.redhat.com/show_bug.cgi?id=1475741
>  - golang-bazil-fuse - Go library for writing FUSE userspace filesystems
>https://bugzilla.redhat.com/show_bug.cgi?id=1475750
>  - golang-github-Unknwon-goconfig - Configuration file parser for the Go
>Programming Language
>https://bugzilla.redhat.com/show_bug.cgi?id=1475763
>  - golang-github-ncw-go-acd - Go library for accessing the Amazon Cloud
>Drive
>https://bugzilla.redhat.com/show_bug.cgi?id=1475841
>  - golang-github-ncw-dropbox-sdk-go-unofficial - An unofficial Go SDK
>for integrating with the Dropbox API v2
>https://bugzilla.redhat.com/show_bug.cgi?id=1475832
>  - golang-github-nsf-termbox-go - A minimalistic API which allows
>programmers to write text-based user interfaces
>https://bugzilla.redhat.com/show_bug.cgi?id=1475846
>  - golang-github-rfjakob-eme - Encrypt-Mix-Encrypt for Go
>https://bugzilla.redhat.com/show_bug.cgi?id=1475850
>  - golang-github-xanzy-ssh-agent - Create a ssh-agent on any type of OS
>from any Go application
>https://bugzilla.redhat.com/show_bug.cgi?id=1475863
>  - golang-github-VividCortex-ewma - Exponentially Weighted Moving Average
>algorithms for Go
>https://bugzilla.redhat.com/show_bug.cgi?id=1475791
>
>  Thanks.
>
>  Robert-André Mauchin
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org



-- 
With best regards, Peter Lemenkov.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: No i686 build of grub2?

[Jeff Backus]

On Wed, Aug 23, 2017 at 10:47 AM, Peter Jones  wrote:

> On Wed, Aug 23, 2017 at 07:27:44AM -0500, Bruno Wolff III wrote:
> > Currently grub2 isn't being built for i686 since somewhere between 2.02-8
> > and 2.02-10.
> > I looked through the change log (but not the git log yet) and didn't see
> > anything mentioning this, which I would have expected if it was an
> > intentional change.
> > So is this a new permanent feature going forward or a temporary oops?
> > (I still have one machine I use regularly, that only runs i686 and it
> will
> > probably be a while before I can afford to replace it.)
>
> It is still built as grub2-pc{,-modules}, just built a bit differently.
> I'll figure out how to re-work it so you won't see a problem, thanks for
> the heads up.
>
>
My apologies for being late to the party.

Peter, I see that you updated the spec file to fix i686 building. Does that
mean that everything is resolved?

jeff

-- 
Jeff Backus
jeff.bac...@gmail.com
http://github.com/jsbackus
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: No i686 build of grub2?

[Jeff Backus]

On Wed, Aug 23, 2017 at 9:13 AM, Bruno Wolff III  wrote:

> On Wed, Aug 23, 2017 at 08:57:30 -0400,
>  Mauricio Tavares  wrote:
>
>> I think I read here (or in other mailing list) about an interest in
>> dropping 32bit altogether. But this might be just my imagination.
>>
>
> Certainly there was a discussion, but I hadn't heard this was definitive,
> or that it was going to start in f27. (I'm using f28, but the change
> happened to f27 builds around the branch time.) I would expect this
> actually being done to be worthy of an announcement. That's why I think
> this might be a temporary issue. But how I work around it will depend on
> whether on not there will be official i686 builds again soon.
>
>
Sorry for the late response. It is definitive. See FESCo ticket #1737 (
https://pagure.io/fesco/issue/1737). The x86 SIG has until September 8th to
get organized, or i686 gets pulled from the official kernels.

So, anyone who still uses i686: Now's a great time to join up.
https://fedoraproject.org/wiki/Architectures/x86

jeff

Jeff Backus
jeff.bac...@gmail.com
http://github.com/jsbackus
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

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

[Marcin Juszkiewicz]

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

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

Re: Translations in an RPM spec

[Tomasz Kłoczko]

On 26 August 2017 at 16:21, Björn Persson  wrote:

> Tomasz Kłoczko wrote:
> > This how it IMO should be done:
> [..]
> That looks like a good plan for how large numbers of translators can
> contribute translations to many different languages.
>
> Writing the translations directly in the spec doesn't scale well when
> there are many languages and many translators, but it's very convenient
> in the special case where the translator is also the package maintainer.
> For the maintainer it would be much more trouble to edit the English
> description, commit and push, wait for the translation system to get
> updated, edit the translation in a different tool, and finally commit
> and push again.
>
> So to anyone who decides to implement Tomasz' proposal, please make it
> work together with translations in the spec, not replace them.
>

Just two more thoughts:
1) As long as as sections with "%description [-n]  -l
" can be added in almost any place of the spec fie seems like it is
some easy way about how to add all translations without touching original
package spec files maintained in packages git repos.
In global macros is after include all macros can be added fragment like:

if [ %{_specdir}/%{name}.spec.i18n ]; then
  %include %{_specdir}/%{name}.i18n
fi

standard %clean probably could be extended to remove this file after build
if it will be injected to build process in exactly this directory.
IMO adding translations should be not a part of the standard rpm macros and
should be present only in koji so above if with %include probably could be
added in build account ~/.rpmrc. or by adding some new file in
/usr/lib/rpm/macros.d/ or even add redefine %_spec_prep_pre in command line
to add add %include.

2) Adding all Summary() will be probably a bit more tricky.
To not touch original spec files probably best would be extend current
Summary field syntax to something like:

Summary(,[[-n ]]): 

This IMO more likely would allow to add on build stage dynamically all
available translations transparently without bothering each packages
maintainers.

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

Re: retired packages in rawhide/f27

[Kevin Fenzi]

On 08/27/2017 11:11 PM, Honggang LI wrote:
> On Tue, Aug 22, 2017 at 09:29:58AM -0700, Kevin Fenzi wrote:
>> On 08/22/2017 02:30 AM, Petr Pisar wrote:
>>> On 2017-08-22, Honggang LI  wrote
...snip...

> 
> I will file tickets to retire those packages as "fedpkg retire" can't
> retire them.

No need. We tracked down this issue and it was due to rawhide releng
scripts not being properly updated for branching. If you look now, all
those packages should be blocked in both f27 and f28.

(use koji list-pkgs --package=rmda --show-blocked ) to show them.

>> In any case, due to the rdma-core not building on armv7, blocking these
>> packages currently breaks composes. (Thats one reason why we have not
>> had a branched compose in a while).
>>
>> So, I would appreciate it if you could leave f28/rawhide for now (since
>> we do get composes there) until we get lorax set to handle things.
> 
> No, we will *not* leave them for f28/rawhide or f27. With awilliam's and
> kaleb's help, the packages depend on libibverbs had been rebuilt. I also
> rebuilt five packages depend on libibumad. The rest of two packages, pcp
> and papi will be rebuilt in today. Please see [1] for details.
> 
> [1] https://bugzilla.redhat.com/show_bug.cgi?id=1484155

Right, I meant leave them until things were fixed, which you all have done.

Thank you

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

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

[Zbigniew Jędrzejewski-Szmek]

On Mon, Aug 28, 2017 at 02:11:16PM +0200, Marcin Juszkiewicz wrote:
> W dniu 12.08.2017 o 17:15, Zbigniew Jędrzejewski-Szmek pisze:
> > atomic-reactor/   ftbfs (AttributeError: module 'docker' has no 
> > attribute 'Client')
> 
> Looks like it uses 'docker-py' rather than 'docker' one which is the one
>  other projects migrated to.
> 
> docker.Client -> docker.APIClient rename happened but I do not know were
> there other changes.

Yeah, it probably isn't even too hard to fix, but it should be done by the
maintainers of the package. This isn't something for a drive-by contributor.

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

Re: Mass package change (python2- binary package renaming)

[Zbigniew Jędrzejewski-Szmek]

On Mon, Aug 28, 2017 at 02:01:19PM +0200, Sandro Mani wrote:
> 
> 
> On 28.08.2017 10:04, Johannes Lips wrote:
> >I would like to add, that apparently the capitalization of subpackages also 
> >changed. This broke dependencies for me. I don't know if this was intended.

This is on purpose: the new names that were generated are always lowercase,
as recommended by current guidelines.

> >https://bugzilla.redhat.com/show_bug.cgi?id=1485703
Provides/Obsoletes for the old name should have been provided, but in some
cases (where just the case changed, and the old name had python- format)
they were skipped by mistake.

Björn Esser added the missing Provides and rebuilt the package in rawhide,
so this is already fixed.

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

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

[Marcin Juszkiewicz]

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

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

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

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

[Zbigniew Jędrzejewski-Szmek]

On Wed, Aug 23, 2017 at 11:39:20AM +0200, Kalev Lember wrote:
> On 08/23/2017 02:00 AM, Kevin Fenzi wrote:
> > Also, I'd like to very much thank you for doing this work. :)
> > It's great to get done, it's great to do it quickly and I know it's a
> > lot of hard work to script and build things.
> 
> Yes, thank you for doing this, Zbyszek!

Thanks ;)

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

Re: Mass package change (python2- binary package renaming)

[Sandro Mani]

On 28.08.2017 10:04, Johannes Lips wrote:

I would like to add, that apparently the capitalization of subpackages also 
changed. This broke dependencies for me. I don't know if this was intended. 
Please see:
https://bugzilla.redhat.com/show_bug.cgi?id=1485703
If it was intended, I am happy to fix this, otherwise please check your script 
to prevent more mistakes.
And in general, is the script supposed to also fix the Requires in 
various packages, or do those need to be fixed by hand? For instance 
qgis still has various python-XXX requires which are now broken.


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

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

[Zbigniew Jędrzejewski-Szmek]

On Tue, Aug 22, 2017 at 05:00:05PM -0700, Kevin Fenzi wrote:
> python-basemap seems wrong...
> 
> There's now a python3-basemap and a python2-basemap-examples but no
> python2-basemap. ;(

Oops, sorry for the late reply, I somehow missed this your mail.
My script was confused by the -examples subpackage. Updated version
is building now.

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

Re: [modularity] Modules and AppStream

[Neal Gompa]

On Mon, Aug 28, 2017 at 4:34 AM, Kevin Kofler  wrote:
> Neal Gompa wrote:
>> RPM itself is now sufficiently advanced that it can take on all the
>> roles of composition group metadata. They would essentially be transformed
>> into metapackages. This has already happened on the SUSE side, where
>> their patterns are now just metapackages with Provides that the
>> package manager knows to work from.
>
> Using metapackages or even the good old RPM Group tag could work, if
> 1. we actually ship this information in our packages, and
> 2. tools like Dnfdragora actually know how to use them. (Dnfdragora has
>support for RPM Group tags, but I don't think it supports the SUSE
>approach at this time, does it?)
>

It's in development, as Mageia also uses the same approach (the task-*
packages function the same way that pattern-* packages on SUSE do).



-- 
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: [modularity] Modules and AppStream

[Kevin Kofler]

Neal Gompa wrote:
> RPM itself is now sufficiently advanced that it can take on all the
> roles of composition group metadata. They would essentially be transformed
> into metapackages. This has already happened on the SUSE side, where
> their patterns are now just metapackages with Provides that the
> package manager knows to work from.

Using metapackages or even the good old RPM Group tag could work, if
1. we actually ship this information in our packages, and
2. tools like Dnfdragora actually know how to use them. (Dnfdragora has
   support for RPM Group tags, but I don't think it supports the SUSE
   approach at this time, does it?)

Otherwise, let's please stick to what works (i.e., comps).

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

Re: Mysterious build, perhaps tagged to wrong release?

[Sandro Mani]

On 28.08.2017 02:03, Kevin Kofler wrote:

Sandro Mani wrote:

Right, I suppose given the smallish audience affected by this, it's
better to violate the update guidelines once than introducing a
permanent epoch bump.

FYI, there are still ongoing plans to upgrade the native qt5-qtbase in F26
to 5.9.1, you may want to follow suit with mingw-qt5-qtbase when that
happens. I would also stick to 5.8.0 for now.
I was actually meaning to ask whether there were plans for that. Any 
idea when it will be? Because I'm tempted to go straight to 5.9.1, so 
that I can just git merge && fedpkg build the entire series.


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

Re: Mass package change (python2- binary package renaming)

[Johannes Lips]

I would like to add, that apparently the capitalization of subpackages also 
changed. This broke dependencies for me. I don't know if this was intended. 
Please see:
https://bugzilla.redhat.com/show_bug.cgi?id=1485703
If it was intended, I am happy to fix this, otherwise please check your script 
to prevent more mistakes.

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

Re: F28 System Wide Change: Switch libidn-using applications to IDNA2008

[Kamil Dudka]

On Monday, August 28, 2017 1:59:42 AM CEST Kevin Kofler wrote:
> Björn Persson wrote:
> 
> > To me it looks like an attempt to recruit packagers to help promoting
> > the change _upstream_.
> 
> 
> There is no upstream for kdelibs3. It is a compatibility package, which is
> 2 major (first digit!) versions behind what upstream actually develops. We
> are mostly only backporting security fixes and compilation fixes, so that
> legacy applications keep running.
> 
> 
> > Look at what packagers are actually asked to do:
> > 
> > 
> >> Propose patches to convert to libidn2, and notify upstream about it.
> > 
> > 
> > Note well the words "propose", "notify" and "upstream". How is that
> > equivalent to blindly enforcing the change without assessing the impact?
> 
> 
> It is when we are talking about a package like kdelibs3.

OK.  That is a fair reason to relink kdelibs3 against libidn2 without 
notifying upstream.  But it does not mean that we should enforce such
approach for the rest of Fedora packages...

Kamil

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

Re: F28 System Wide Change: Switch libidn-using applications to IDNA2008

[Nikos Mavrogiannopoulos]

On Fri, 2017-08-25 at 08:56 -0500, Michael Catanzaro wrote:
> On Fri, Aug 25, 2017 at 1:24 AM, Jan Kurik  wrote:
> > The proposed change is about deprecating libidn, which supports
> > IDNA2003, and switch all applications using libidn, to libidn2
> > 2.0.0,
> > which supports IDNA2008.
> 
> Any plans to migrate applications that use ICU's deprecated IDNA2003 
> functions?

I'm not familiar with ICU so I left it outside the scope of that
change. However, it would make sense to have a larger change that
includes ICU as well.

Currently most challenges were on subtle incompatibilities between
libidn and libidn2.

> Thanks for pointing out that WebKit has (quite recently) switched to 
> nontransitional IDNA2008. Epiphany is still doing transitional 
> processing. I'll turn that off now.

Note that as a browser you may want to be as compatible as possible.
Firefox for example switches to IDNA transitional (i.e., 2003) when the
string cannot be expressed in IDNA2008 (e.g., contains disallowed
characters). With libidn2 that can be expressed as:
https://libidn.gitlab.io/libidn2/manual/libidn2.html#Converting-with-backwards-compatibility

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

Re: F28 System Wide Change: Switch libidn-using applications to IDNA2008

[Nikos Mavrogiannopoulos]

On Fri, 2017-08-25 at 14:38 +0200, Kevin Kofler wrote:
> Jan Kurik wrote:
> > * Other developers:
> > Maintainers, should
> > - Verify that their software is linked with the libidn library
> > - Update the software from upstream if it already has been
> > converted to
> > libidn2
> > - Check the libidn2 instructions on converting a package to
> > libidn2.
> > - Propose patches (trivial task) to convert to libidn2, and
> > notify upstream about it.
> > In short switch software from libidn to libidn2, it is sufficient
> > replacing idna.h header with idn2.h.
> 
> I repeat again what I already wrote when this was initially
> announced, 
> because it was ignored:
> 
> I do not see why we need to patch each and every application for
> this. Since 
> the library is at least API-compatible (not sure about the ABI),
> libidn2-
> devel should have Obsoletes and Provides for libidn-devel and
> symlinks 
> libidn.so → libidn2.so and idn.h → idn2.h. Then all that is needed
> in 
> application packages is a rebuild. Changing one package scales much
> better 
> than changing all other packages.

libidn contains more than IDNA2003 functionality, such as stringprep et
al. Libidn2 contains only IDNA2008 functionality, so there cannot be a
1-1 mapping between the two libraries and libidn2 cannot replace libidn
for the protocols which still rely on stringprep. Stringprep is an
IDNA2003 requirement but some protocols such as XMPP rely on it.

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