Re: [ACTION NEEDED #2] Missing BuildRequires: gcc/gcc-c++

[Emmanuel Seyman]

* Igor Gnatenko [07/03/2018 08:43] :
>
> This is the second iteration of my mass-scratch-rebuild without
> gcc/gcc-c++ in the buildroot[0]. Everything what was written in
> original mail still applies.

I've fixed the following:

perl-AI-DecisionTree
perl-Algorithm-FastPermute
perl-Algorithm-SVM
perl-CSS-Minifier-XS
perl-Crypt-RC4-XS
perl-FCGI
perl-GStreamer-Interfaces
perl-Geo-IP
perl-HTML-Template-Pro
perl-Search-Xapian
perl-Socket-MsgHdr
perl-Sys-CPU
perl-Text-CHM
perl-Text-CharWidth
perl-Text-ExtractWords
perl-Text-Ngram
perl-Tk-TableMatrix
perl-URI-Escape-XS
perl-Unicode-Map8
perl-Unicode-String
perl-XML-Bare
perl-re-engine-RE2

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

Re: new section for 'Join the package collection maintainers'

[Athos Ribeiro]

On Tue, Mar 13, 2018 at 12:35:19AM +0100, René Genz wrote:
> the other day I wanted to contribute a fix to an RPM package's spec file.
> 
> I struggled with uploading my changes to my fork on src.fedoraproject.org.
> puiterwijk and clime from #fedora-admin IRC channel on freenode.net pointed 
> me in the right direction:
> * 'packager' status for FAS account required, else all repos, including 
> forks, are read-only
> * workaround is to use a "Remote pull-request"
> * requirement of 'packager' status is being worked on.
> 
> With this information contributing the fix was easy.
> 
[snip...]
> 
> Now I try to add the information to Fedora's documentation.
> From my point of view, this would be a good website:
> https://fedoraproject.org/wiki/Join_the_package_collection_maintainers
> 
> 
> I propose to:
> add a new major point 2, so:
> "2. How to join the Fedora Package Collection Maintainers?"
> will be:
> "3. How to join the Fedora Package Collection Maintainers?"
> 
> The new major point 2 would be something like:
> ---8<---
> 2. Notes for one-off contributors
> 
> Your contribution is welcome.
> 
> At first you must  (https://fedoraproject.org/wiki/Join_the_package_collection_maintainers?rd=PackageMaintainers/Join#Create_a_Fedora_Account)>.
> 
> Before proceeding, please sync your account by login on 
> https://src.fedoraproject.org/ using your FAS credentials.

See 2.3.1 - It deals with the FAS account creation. Maybe you could link
there to avoid replication :)

> 
> At the moment any repos, including forks, on https://src.fedoraproject.org 
> require your FAS account to have 'packager' status for write access (and read 
> access if you use the "SSH" Source GIT URL).
>
> Either you get the status or you use a  (https://docs.pagure.org/pagure/usage/pull_requests.html#remote-git-to-pagure-pull-request)>,
>  f.e. with https://pagure.io/new)>, as a workaround.
> The requirement to be a packager is being worked on.
> ---8<---

I would rather see something like:

If you are not an Fedora packager, i.e., you are not in the 'packager'
FAS group, you can send pull requests to  src.fedoraproject.org. To do
so, you must use a https://docs.pagure.org/pagure/usage/pull_requests.html#remote-git-to-pagure-pull-request)>,
f.e. with https://pagure.io/new)>

Also, I do not understood what you meant with

"The requirement to be a packager is being worked on."

> 
> What do you think?

I think it is valuable information and should be added to the wiki :)
Thanks!

> I can edit the wiki.

Can you? Note that to edit the wiki you must be in at least one extra
FAS group other the the CLA ones.


-- 
Athos Ribeiro

http://www.ime.usp.br/~athoscr
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

new section for 'Join the package collection maintainers'

[René Genz]

Dear sir or madam,

the other day I wanted to contribute a fix to an RPM package's spec file.

I struggled with uploading my changes to my fork on src.fedoraproject.org.
puiterwijk and clime from #fedora-admin IRC channel on freenode.net pointed me 
in the right direction:
* 'packager' status for FAS account required, else all repos, including forks, 
are read-only
* workaround is to use a "Remote pull-request"
* requirement of 'packager' status is being worked on.

With this information contributing the fix was easy.

I could not find the information given on IRC channel in the documentation of 
Fedora or Pagure.
Hence I created a pull-request to update Pagure's documentation:
https://pagure.io/pagure/pull-request/3057

pingou would rather not include it in Pagure's documentation because, from his 
point of view, it is too specific to https://src.fedoraproject.org for Pagure's 
documentation.

I will remove my proposal to modify "doc/usage/pull_requests.rst" from the pull 
request. Hence I write it down here as a reference:
* add at line 5:
At the moment any repos, including forks, on `src.fedoraproject.org 
` require your `FAS account 
` to have 'packager' status for 
write access (and read access if you use the "SSH" Source GIT URL).
Either you request the status or you use the 
:ref:`Remote-Git-to-Pagure-pull-request` workaround.
The requirement to be a packager is being worked on.

* replace at line 23:
You can create a pull request from another git hosting platform (e.g. GitHub, 
GitLab).
with:
You can create a pull request from another git hosting platform (e.g. `Pagure 
` (for src.fedoraproject.org), GitHub, GitLab).



Now I try to add the information to Fedora's documentation.
From my point of view, this would be a good website:
https://fedoraproject.org/wiki/Join_the_package_collection_maintainers


I propose to:
add a new major point 2, so:
"2. How to join the Fedora Package Collection Maintainers?"
will be:
"3. How to join the Fedora Package Collection Maintainers?"

The new major point 2 would be something like:
---8<---
2. Notes for one-off contributors

Your contribution is welcome.

At first you must https://fedoraproject.org/wiki/Join_the_package_collection_maintainers?rd=PackageMaintainers/Join#Create_a_Fedora_Account)>.

Before proceeding, please sync your account by login on 
https://src.fedoraproject.org/ using your FAS credentials.

At the moment any repos, including forks, on https://src.fedoraproject.org 
require your FAS account to have 'packager' status for write access (and read 
access if you use the "SSH" Source GIT URL).
Either you get the status or you use a https://docs.pagure.org/pagure/usage/pull_requests.html#remote-git-to-pagure-pull-request)>,
 f.e. with https://pagure.io/new)>, as a workaround.
The requirement to be a packager is being worked on.
---8<---

What do you think?
I can edit the wiki.
I ask first in order to avoid an edit war.

It is OK for me if you do not want this change. Just let me know.
-- 
Best regards,
René
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Fedora Rawhide-20180312.n.0 compose check report

[Fedora compose checker]

No missing expected images.

Failed openQA tests: 20/137 (x86_64), 5/23 (i386), 1/2 (arm)

ID: 201883  Test: x86_64 Server-dvd-iso server_role_deploy_domain_controller
URL: https://openqa.fedoraproject.org/tests/201883
ID: 201889  Test: x86_64 Server-dvd-iso server_role_deploy_database_server
URL: https://openqa.fedoraproject.org/tests/201889
ID: 201920  Test: i386 Workstation-boot-iso memory_check
URL: https://openqa.fedoraproject.org/tests/201920
ID: 201921  Test: i386 Workstation-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/201921
ID: 201922  Test: x86_64 KDE-live-iso desktop_notifications_live
URL: https://openqa.fedoraproject.org/tests/201922
ID: 201923  Test: x86_64 KDE-live-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/201923
ID: 201927  Test: x86_64 KDE-live-iso install_no_user
URL: https://openqa.fedoraproject.org/tests/201927
ID: 201935  Test: arm Minimal-raw_xz-raw.xz 
install_arm_image_deployment_upload
URL: https://openqa.fedoraproject.org/tests/201935
ID: 201939  Test: x86_64 AtomicWorkstation-dvd_ostree-iso 
install_default_upload
URL: https://openqa.fedoraproject.org/tests/201939
ID: 201940  Test: x86_64 AtomicWorkstation-dvd_ostree-iso 
install_default@uefi
URL: https://openqa.fedoraproject.org/tests/201940
ID: 201941  Test: x86_64 AtomicWorkstation-dvd_ostree-iso install_no_user
URL: https://openqa.fedoraproject.org/tests/201941
ID: 201954  Test: x86_64 universal install_cyrillic_language
URL: https://openqa.fedoraproject.org/tests/201954
ID: 201962  Test: x86_64 universal install_xfs@uefi
URL: https://openqa.fedoraproject.org/tests/201962
ID: 201981  Test: x86_64 universal upgrade_2_kde_64bit
URL: https://openqa.fedoraproject.org/tests/201981
ID: 201982  Test: x86_64 universal upgrade_2_desktop_encrypted_64bit
URL: https://openqa.fedoraproject.org/tests/201982
ID: 201988  Test: x86_64 universal upgrade_server_domain_controller
URL: https://openqa.fedoraproject.org/tests/201988
ID: 201992  Test: x86_64 universal upgrade_2_minimal_64bit
URL: https://openqa.fedoraproject.org/tests/201992
ID: 201993  Test: x86_64 universal upgrade_2_desktop_64bit
URL: https://openqa.fedoraproject.org/tests/201993
ID: 201995  Test: x86_64 universal install_blivet_xfs@uefi
URL: https://openqa.fedoraproject.org/tests/201995
ID: 202001  Test: x86_64 universal install_package_set_kde
URL: https://openqa.fedoraproject.org/tests/202001
ID: 202012  Test: x86_64 universal install_iscsi
URL: https://openqa.fedoraproject.org/tests/202012
ID: 202015  Test: x86_64 universal upgrade_2_server_64bit
URL: https://openqa.fedoraproject.org/tests/202015
ID: 202027  Test: i386 universal install_simple_encrypted
URL: https://openqa.fedoraproject.org/tests/202027
ID: 202035  Test: i386 universal upgrade_2_desktop_32bit
URL: https://openqa.fedoraproject.org/tests/202035
ID: 202036  Test: i386 universal install_package_set_kde
URL: https://openqa.fedoraproject.org/tests/202036
ID: 202162  Test: x86_64 Workstation-live-iso desktop_update_graphical
URL: https://openqa.fedoraproject.org/tests/202162

Soft failed openQA tests: 62/137 (x86_64), 15/23 (i386)
(Tests completed, but using a workaround for a known bug)

ID: 201875  Test: x86_64 Server-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/201875
ID: 201876  Test: x86_64 Server-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/201876
ID: 201878  Test: x86_64 Server-dvd-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/201878
ID: 201879  Test: x86_64 Server-dvd-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/201879
ID: 201881  Test: x86_64 Server-dvd-iso install_repository_nfs_variation
URL: https://openqa.fedoraproject.org/tests/201881
ID: 201882  Test: x86_64 Server-dvd-iso install_repository_nfs_graphical
URL: https://openqa.fedoraproject.org/tests/201882
ID: 201898  Test: i386 Server-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/201898
ID: 201899  Test: i386 Server-dvd-iso install_default
URL: https://openqa.fedoraproject.org/tests/201899
ID: 201900  Test: x86_64 Everything-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/201900
ID: 201901  Test: x86_64 Everything-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/201901
ID: 201902  Test: i386 Everything-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/201902
ID: 201937  Test: x86_64 AtomicHost-dvd_ostree-iso install_default
URL: https://openqa.fedoraproject.org/tests/201937
ID: 201938  Test: x86_64 AtomicHost-dvd_ostree-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/201938
ID: 201948  Test: x86_64 universal install_shrink_ext4
URL: https://openqa.fedoraproject.org/tests/201948
ID: 201949  Test: x86_64 universal install_shrink_ntfs

Fedora 28-20180312.n.0 compose check report

[Fedora compose checker]

No missing expected images.

Failed openQA tests: 19/137 (x86_64), 5/24 (i386), 1/2 (arm)

ID: 202264  Test: x86_64 Server-dvd-iso server_role_deploy_domain_controller
URL: https://openqa.fedoraproject.org/tests/202264
ID: 202270  Test: x86_64 Server-dvd-iso server_role_deploy_database_server
URL: https://openqa.fedoraproject.org/tests/202270
ID: 202301  Test: i386 Workstation-boot-iso memory_check
URL: https://openqa.fedoraproject.org/tests/202301
ID: 202302  Test: i386 Workstation-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/202302
ID: 202303  Test: x86_64 KDE-live-iso desktop_notifications_live
URL: https://openqa.fedoraproject.org/tests/202303
ID: 202311  Test: x86_64 KDE-live-iso desktop_update_graphical
URL: https://openqa.fedoraproject.org/tests/202311
ID: 202313  Test: x86_64 KDE-live-iso desktop_browser
URL: https://openqa.fedoraproject.org/tests/202313
ID: 202314  Test: x86_64 KDE-live-iso desktop_notifications_postinstall
URL: https://openqa.fedoraproject.org/tests/202314
ID: 202317  Test: arm Minimal-raw_xz-raw.xz 
install_arm_image_deployment_upload
URL: https://openqa.fedoraproject.org/tests/202317
ID: 202321  Test: x86_64 AtomicWorkstation-dvd_ostree-iso 
install_default_upload
URL: https://openqa.fedoraproject.org/tests/202321
ID: 202322  Test: x86_64 AtomicWorkstation-dvd_ostree-iso 
install_default@uefi
URL: https://openqa.fedoraproject.org/tests/202322
ID: 202323  Test: x86_64 AtomicWorkstation-dvd_ostree-iso install_no_user
URL: https://openqa.fedoraproject.org/tests/202323
ID: 202336  Test: x86_64 universal install_cyrillic_language
URL: https://openqa.fedoraproject.org/tests/202336
ID: 202337  Test: x86_64 universal install_blivet_ext3@uefi
URL: https://openqa.fedoraproject.org/tests/202337
ID: 202343  Test: x86_64 universal install_ext3@uefi
URL: https://openqa.fedoraproject.org/tests/202343
ID: 202352  Test: x86_64 universal install_kickstart_nfs
URL: https://openqa.fedoraproject.org/tests/202352
ID: 202355  Test: x86_64 universal install_kickstart_user_creation
URL: https://openqa.fedoraproject.org/tests/202355
ID: 202370  Test: x86_64 universal upgrade_server_domain_controller
URL: https://openqa.fedoraproject.org/tests/202370
ID: 202383  Test: x86_64 universal install_package_set_kde
URL: https://openqa.fedoraproject.org/tests/202383
ID: 202389  Test: x86_64 universal install_xfs
URL: https://openqa.fedoraproject.org/tests/202389
ID: 202394  Test: x86_64 universal install_iscsi
URL: https://openqa.fedoraproject.org/tests/202394
ID: 202399  Test: x86_64 universal install_kickstart_hdd
URL: https://openqa.fedoraproject.org/tests/202399
ID: 202409  Test: i386 universal install_simple_encrypted
URL: https://openqa.fedoraproject.org/tests/202409
ID: 202417  Test: i386 universal upgrade_2_desktop_32bit
URL: https://openqa.fedoraproject.org/tests/202417
ID: 202418  Test: i386 universal install_package_set_kde
URL: https://openqa.fedoraproject.org/tests/202418

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

ID: 202256  Test: x86_64 Server-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/202256
ID: 202257  Test: x86_64 Server-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/202257
ID: 202259  Test: x86_64 Server-dvd-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/202259
ID: 202260  Test: x86_64 Server-dvd-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/202260
ID: 202262  Test: x86_64 Server-dvd-iso install_repository_nfs_variation
URL: https://openqa.fedoraproject.org/tests/202262
ID: 202263  Test: x86_64 Server-dvd-iso install_repository_nfs_graphical
URL: https://openqa.fedoraproject.org/tests/202263
ID: 202276  Test: x86_64 Server-dvd-iso install_updates_nfs
URL: https://openqa.fedoraproject.org/tests/202276
ID: 202279  Test: i386 Server-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/202279
ID: 202280  Test: i386 Server-dvd-iso install_default
URL: https://openqa.fedoraproject.org/tests/202280
ID: 202281  Test: x86_64 Everything-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/202281
ID: 202282  Test: x86_64 Everything-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/202282
ID: 202283  Test: i386 Everything-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/202283
ID: 202319  Test: x86_64 AtomicHost-dvd_ostree-iso install_default
URL: https://openqa.fedoraproject.org/tests/202319
ID: 202320  Test: x86_64 AtomicHost-dvd_ostree-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/202320
ID: 202330  Test: x86_64 universal install_shrink_ext4
URL: https://openqa.fedoraproject.org/tests/202330
ID: 202331  Test: x86_64 universal install_shrink_ntfs
URL: 

Re: Gating packages in Rawhide

[Randy Barlow]

On 03/09/2018 04:20 AM, Pierre-Yves Chibon wrote:
> I had a different idea in mind, basically try to keep the experience as close 
> as
> what it is now.
> for single package:
>   - packager commit
>   - packager build
>   - build is tagged into a specfic koji tag
>   - test are run on this tag
> -> results go to src.fp.o
>   - if tests pass
> - package is moved to another koji tag
> - package is signed
> - package is pushed to rawhide
>   - if tests do not pass
> - do nothing
> - if the user submits a waiver
>   - move the package to the next koji tag for signing it
> If a packager does not want to run the tests, we could have a fedpkg build
> --noci that would directly build the package in the koji tag used for signing
> the package (useful for mass-rebuild for example)

I would really like to have tests in src.fpo, but I think they would be
most helpfully displayed on pull requests, rather than after I've
already made a Koji build. This is more similar to the workflow I'm
accustomed to when I work on Bodhi's upstream code - I submit a PR and
CentOS CI (which is very nice btw) chews on it and tells me if I'm good
to merge. For a single package update (which is most of what I
personally do) it would be very nice to have this before I merge my PR
in Pagure.

So all that to say that I like the above, but I'd like to propose that
there also be some tests run before I commit (i.e., merge the PR) and
build in Koji (for cases where we use PRs. I'm not proposing we require
PRs, but that it be available for those of us who would like to use that
workflow). PRs do get the simplekojici build today, which is cool. I'd
really just like a few more tests than that to be run as well.

> for multi-package:
>   - packager requests a new side-tag (I'd propose via bodhi)
>   - packager build all the different packages in that side-tag
>   - packager asks for the side tag to be merged
>   - tests are run on all these packages
> -> results go to src.fp.o

At this point there aren't pull requests, right? Where would we display
this in src.fp.o that would make it clear which change the test results
pertain to?

> --> We probably want to also report them on the bodhi request to merge the
> tag as otherwise the packager will have to go through all the package 
> to
> find the one(s) that failed

Do you mean that Bodhi would display them on a side tag page? Or in this
scenario are you suggesting that a Bodhi update has been created? The
update would be less friction since we already have code to display test
results on Bodhi updates.

> The idea to automatically build upon commit is neat and something we can look
> into, but I think it can be approached separately from gating rawhide, one
> doesn't require the other.
> Speaking of both changes in one go might confuse things a little.

True, it's orthogonal.



signature.asc
Description: OpenPGP digital signature
___
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 2018-03-13 from 10:00:00 to 11:00:00 US/Eastern
   At fedora-modular...@chat.freenode.net

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: Gating packages in Rawhide

[Randy Barlow]

On 03/08/2018 10:53 PM, Kevin Kofler wrote:
> IMHO, this is highly impractical. Having to file Bodhi updates for every 
> Rawhide build will make development cringe to a halt.

The proposal is to automate the filing of Bodhi updates, so in most
cases you would not really interact with them unless tests fail. I
hinted at a "perhaps 1 day", but it was suggested elsewhere that we
could also not have any time restrictions and just send it to stable as
soon as automated tests pass. I don't have strong feelings about the
policy there, so if we went that direction you might not even notice
Bodhi is involved unless the tests fail (in which case you should take
action anyway).

> Some automation would help, sure. But if we are going to do things 
> automatically, why bother with Bodhi at all?

As nirik said, because we have it. Bodhi's mission in life is gating[0],
and we want to gate Rawhide. We have a tool that does that now, and it's
easier to use it (even if it would need a few changes) than it is to
create another service.

> We are already building into a pending tag for the autosigning, from which 
> the packages are moved into the final tag when they are signed. The same 
> process should work for autotesting. Just add it before or after the 
> autosigning in the pipeline, possibly with another intermediate tag.

The "it" is the thing we don't have, outside of a conveniently already
created tool.

> I think that Bodhi is really the wrong tool for the job here. What you are 
> trying to hit with your shiny hammer may look like a nail to you, but it is 
> really a screw. ;-)

After having been in Bodhi's JSON rendering code today, it doesn't look
so shiny to me, but thanks for the compliment.

As I said, Bodhi's mission is gating, and gating is the proposal here,
so I think it is actually a good tool to use.


[0] I more generally think of Bodhi as a community driven Koji admin.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Gating packages in Rawhide

[Randy Barlow]

On 03/09/2018 04:06 AM, Pierre-Yves Chibon wrote:
>> To be fair, there was a suggestion that we show results in
>> pagure/src.fedoraproject.org, but to me, that definitely sounds like the
>> wrong place for such things. We want tests tied to a specific update,
>> not the entire package as a whole. (Even thought we could fudge this by
>> having git tags or something to tie results to).

> For regular Fedora releases I definitely agree with you, but for rawhide where
> the only time we bundle package together would be via side-tags, I think
> reporting test results to src.fp.o would be a valid approach.

I think this would be great when the intended update has only one
package in it. For times when we need to update n packages together it
might be tricky, but perhaps we can think of a way to indicate that a
set of patches to different repositories are meant to be a single atomic
change.



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: F28 System Wide Change: Replace glibc's libcrypt with libxcrypt

[Michael Schwendt]

> The example in "man encrypt" is the culprit. It extracts the bits from
> each byte upwards into the bit vector, i.e. offset 0 = bit 0 from byte 0,
> offset 1 = bit 1 from byte 0, offset 2 = bit 2 from byte 0 and so on.
> 
> If doing it as in the Claws Mail source code, the ciphertext is the same
> for all three DES APIs. Claws Mail unpacks the bits in decreasing (!) order.
> 
> That looks promising.

The following patch would be one solution:
https://mschwendt.fedorapeople.org/claws-mail-3.16.0-encrypt-nettle.patch
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Gating packages in Rawhide

[Zbigniew Jędrzejewski-Szmek]

On Mon, Mar 12, 2018 at 12:44:39PM -0700, Kevin Fenzi wrote:
> On 03/12/2018 09:35 AM, Pierre-Yves Chibon wrote:
> > On Mon, Mar 12, 2018 at 03:58:13PM +0100, Kevin Kofler wrote:
> >> Pierre-Yves Chibon wrote:
> >>> Do note that the uniqueness constraint that koji has will mitigate things
> >>> there. For a package to be built for -liba and then -libb, the package
> >>> will need to have its release field bumped twice.
> >>
> >> Sure, but that has not prevented conflicts in the past either, because it 
> >> does not ensure that the second bump is actually built against the new 
> >> library for which the first bump was committed.
> > 
> ...snip...
> > 
> > Solutions:
> > - Do not allow one package to be in two side-tags at the same time?
> 
> I think this would be difficult...
> 
> > - Ensure the tests for Case #2 would prevent the merge (doable?)
> 
> Yeah, that might be nice. In fact if it's a library so change it would
> easy because there would be broken deps.
> 
> > - Figure out if between build and side-tag merge-request one of the package 
> > in
> >   that side tags has been part of another side-tag (definitely doable, 
> > "just" a
> >   little more logic)
> > - Another idea?
> 
> I think these cases are rare and also that maintainers should
> communicate, so they should be detected.

Actually even the changelog entry should be enough to "communicate" this:
When I see "- rebuilt for foo-n", it's pretty obvious that I need to make
sure to include foo-n in my build environment.

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

Re: Gating packages in Rawhide

[Kevin Fenzi]

On 03/12/2018 09:35 AM, Pierre-Yves Chibon wrote:
> On Mon, Mar 12, 2018 at 03:58:13PM +0100, Kevin Kofler wrote:
>> Pierre-Yves Chibon wrote:
>>> Do note that the uniqueness constraint that koji has will mitigate things
>>> there. For a package to be built for -liba and then -libb, the package
>>> will need to have its release field bumped twice.
>>
>> Sure, but that has not prevented conflicts in the past either, because it 
>> does not ensure that the second bump is actually built against the new 
>> library for which the first bump was committed.
> 
...snip...
> 
> Solutions:
> - Do not allow one package to be in two side-tags at the same time?

I think this would be difficult...

> - Ensure the tests for Case #2 would prevent the merge (doable?)

Yeah, that might be nice. In fact if it's a library so change it would
easy because there would be broken deps.

> - Figure out if between build and side-tag merge-request one of the package in
>   that side tags has been part of another side-tag (definitely doable, "just" 
> a
>   little more logic)
> - Another idea?

I think these cases are rare and also that maintainers should
communicate, so they should be detected.

Notifications of builds and/or commits should definitely tell a
maintainer that two people are rebuilding things in two side tags.

Perhaps when creating a side tag we could display the existing ones so
you know if what you are trying to do might overlap with an existing
one? For that we might need a short description of the side tag...

f29-kevin-xfce "Side tag to build the Xfce stack"
or
f29-exampleuser-boost "Side tag to rebuild against new boost x.y.z"

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: Gating packages in Rawhide

[Kevin Fenzi]

On 03/12/2018 04:48 AM, Milan Crha wrote:
>   Hi,
> 
> On Mon, 2018-03-12 at 12:10 +0100, Pierre-Yves Chibon wrote:
>> On Mon, Mar 12, 2018 at 11:33:36AM +0100, Milan Crha wrote:
>>> On Fri, 2018-03-09 at 11:35 -0800, Kevin Fenzi wrote:
 Sure, with this proposal you would:

 * request a side tag
 * build a, wait for it to be added to the repo, build b, etc.
 You would not need to file overrides, just build them in the
 right order with wait-repo between them.
>>>
>> Tooling can be built no? Why do you assume we can't make chain-build
>> work with side-tags?
> 
> That wasn't my suggestion, that's what Kevin Fenzi suggested and I sort
> of questioned it. :)

To be clear I didn't suggest chain build wouldn't work, I just outlined
a workflow I could see myself using. I suspect chain build would work on
a side tag just fine with --target passed to it. But of course we would
want to test and note this use case.

So, thanks for bringing it up...

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 28 compose report: 20180312.n.0 changes

[Fedora Branched Report]

OLD: Fedora-28-20180310.n.0
NEW: Fedora-28-20180312.n.0

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

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

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

= ADDED IMAGES =
Image: AtomicHost qcow2 x86_64
Path: AtomicHost/x86_64/images/Fedora-AtomicHost-28-20180312.n.0.x86_64.qcow2
Image: AtomicHost raw-xz x86_64
Path: AtomicHost/x86_64/images/Fedora-AtomicHost-28-20180312.n.0.x86_64.raw.xz
Image: Server raw-xz armhfp
Path: Server/armhfp/images/Fedora-Server-armhfp-28-20180312.n.0-sda.raw.xz
Image: AtomicHost qcow2 aarch64
Path: AtomicHost/aarch64/images/Fedora-AtomicHost-28-20180312.n.0.aarch64.qcow2
Image: AtomicHost raw-xz aarch64
Path: AtomicHost/aarch64/images/Fedora-AtomicHost-28-20180312.n.0.aarch64.raw.xz
Image: Container_Minimal_Base docker x86_64
Path: 
Container/x86_64/images/Fedora-Container-Minimal-Base-28-20180312.n.0.x86_64.tar.xz

= DROPPED IMAGES =
Image: Cloud boot ppc64le
Path: Cloud/ppc64le/iso/Fedora-Cloud-netinst-ppc64le-28-20180310.n.0.iso
Image: Cloud boot ppc64
Path: Cloud/ppc64/iso/Fedora-Cloud-netinst-ppc64-28-20180310.n.0.iso
Image: Cloud boot s390x
Path: Cloud/s390x/iso/Fedora-Cloud-netinst-s390x-28-20180310.n.0.iso
Image: Cloud boot aarch64
Path: Cloud/aarch64/iso/Fedora-Cloud-netinst-aarch64-28-20180310.n.0.iso
Image: Cloud boot x86_64
Path: Cloud/x86_64/iso/Fedora-Cloud-netinst-x86_64-28-20180310.n.0.iso

= ADDED PACKAGES =

= DROPPED PACKAGES =

= UPGRADED PACKAGES =

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

Re: F28 System Wide Change: Replace glibc's libcrypt with libxcrypt

[Michael Schwendt]

On Mon, 12 Mar 2018 13:12:49 +0100, Michael Schwendt wrote:

> On Fri, 9 Mar 2018 16:32:17 +0100, Florian Weimer wrote:
> 
> > GnuTLS uses Nettle, but does not provide access to DES.  You can use 
> > Nettle directly:
> > 
> > https://www.lysator.liu.se/~nisse/nettle/nettle.html#DES
> > 
> > OpenSSL will work as well, but as Nettle is a preexisting dependency, 
> > it's probably the right choice here.  
> 
> They don't seem to be compatible.
> 
> Whereas Nettle is fully compatible with glibc's rpc/des_crypt.h API, it
> offers a completely different interface than encrypt(), which operates on
> arrays of 64 bytes for each 64-bit block of input.
> 
> The ciphertext returned by encrypt() differs compared with Nettle and
> des_crypt (and that's with the bit vector transformation from the man page).

The example in "man encrypt" is the culprit. It extracts the bits from
each byte upwards into the bit vector, i.e. offset 0 = bit 0 from byte 0,
offset 1 = bit 1 from byte 0, offset 2 = bit 2 from byte 0 and so on.

If doing it as in the Claws Mail source code, the ciphertext is the same
for all three DES APIs. Claws Mail unpacks the bits in decreasing (!) order.

That looks promising.

$ ./encrypt 
passkey = passkey0
Before encrypting: eggplant
After encrypting:  fd 1a 5d 03 ad e5 a6 c2 
After decrypting:  eggplant
$ ./des_crypt
passkey = passkey0
Before encrypting: eggplant
After encrypting:  fd 1a 5d 03 ad e5 a6 c2 
After decrypting:  eggplant
$ ./nettle 
passkey = passkey0
Before encrypting: eggplant
After encrypting:  fd 1a 5d 03 ad e5 a6 c2 
After decrypting:  eggplant
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Configuration file migration without scriptlets

[Jared K. Smith]

On Mon, Mar 12, 2018 at 12:03 PM, Ondřej Lysoněk 
wrote:

> is there any mechanism in Fedora for config file migration? How would
> you make changes to a configuration file (maybe after some config option
> has been renamed), or move a config file to a new location, during
> upgrade? Is there a better way than running 'sed' and 'cp' in a scriptlet?
>
>
In the past, I've used the "augeus" tool to handle configuration file
manipulation.

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

Fedora rawhide compose report: 20180312.n.0 changes

[Fedora Rawhide Report]

OLD: Fedora-Rawhide-20180311.n.1
NEW: Fedora-Rawhide-20180312.n.0

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

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

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

= ADDED IMAGES =

= DROPPED IMAGES =

= ADDED PACKAGES =

= DROPPED PACKAGES =

= UPGRADED PACKAGES =
Package:  ambdec-0.5.1-16.fc29
Old package:  ambdec-0.5.1-15.fc28
Summary:  Ambiosonics decoder for ALSA/JACK
RPMs: ambdec
Size: 1.72 MiB
Size change:  5.02 KiB
Changelog:
  * Mon Mar 12 2018 Orcan Ogetbil  - 
0.5.1-16
  - Use Fedora link flags
  - Add BR: gcc-c++
  - Some cleanup


Package:  anjuta-1:3.28.0-1.fc29
Old package:  anjuta-1:3.26.0-5.fc28
Summary:  GNOME IDE for various programming languages (including C/C++, 
Python, Vala and JavaScript)
RPMs: anjuta anjuta-devel
Size: 41.78 MiB
Size change:  163.71 KiB
Changelog:
  * Sun Mar 11 2018 Kalev Lember  - 1:3.28.0-1
  - Update to 3.28.0
  - Remove ldconfig scriptlets


Package:  control-center-1:3.27.92-1.fc29
Old package:  control-center-1:3.27.90-2.fc28
Summary:  Utilities to configure the GNOME desktop
RPMs: control-center control-center-filesystem
Size: 37.50 MiB
Size change:  739.65 KiB
Changelog:
  * Sun Mar 11 2018 Kalev Lember  - 1:3.27.92-1
  - Update to 3.27.92


Package:  dconf-editor-3.27.92-1.fc29
Old package:  dconf-editor-3.27.91-1.fc29
Summary:  Configuration editor for dconf
RPMs: dconf-editor
Size: 2.98 MiB
Size change:  79.00 KiB
Changelog:
  * Sun Mar 11 2018 Kalev Lember  - 3.27.92-1
  - Update to 3.27.92


Package:  ddrescue-1.23-1.fc29
Old package:  ddrescue-1.22-5.fc29
Summary:  Data recovery tool trying hard to rescue data in case of read 
errors
RPMs: ddrescue
Size: 919.76 KiB
Size change:  16.25 KiB
Changelog:
  * Sun Mar 11 2018 Michal Ambroz  - 1.23-1
  - Update to 1.23.


Package:  dtkcore-2.0.6-1.fc29
Old package:  dtkcore-2.0.5.3-2.fc28
Summary:  Deepin tool kit core modules
RPMs: dtkcore dtkcore-devel
Size: 1.76 MiB
Size change:  220 B
Changelog:
  * Fri Feb 16 2018 mosquito  - 2.0.6-1
  - Update to 2.0.6


Package:  dtkwidget-2.0.6.1-1.fc29
Old package:  dtkwidget-2.0.5.3-3.fc28
Summary:  Deepin tool kit widget modules
RPMs: dtkwidget dtkwidget-devel
Size: 4.99 MiB
Size change:  177.98 KiB
Changelog:
  * Tue Feb 20 2018 mosquito  - 2.0.6.1-1
  - Update to 2.0.6.1


Package:  dtkwm-2.0.6-1.fc29
Old package:  dtkwm-2.0.5-2.fc28
Summary:  Deepin graphical user interface library
RPMs: dtkwm dtkwm-devel
Size: 332.06 KiB
Size change:  2.14 KiB
Changelog:
  * Fri Feb 16 2018 mosquito  - 2.0.6-1
  - Update to 2.0.6


Package:  ebumeter-0.1.0-20.fc29
Old package:  ebumeter-0.1.0-19.fc28
Summary:  Loudness measurement according to EBU-R128
RPMs: ebumeter
Size: 3.91 MiB
Size change:  3.79 KiB
Changelog:
  * Mon Mar 12 2018 Orcan Ogetbil  - 
0.1.0-20
  - Use Fedora link flags
  - Add BR: gcc-c++
  - Some cleanup


Package:  epiphany-1:3.28.0.1-1.fc29
Old package:  epiphany-1:3.28.0-1.fc29
Summary:  Web browser for GNOME
RPMs: epiphany epiphany-runtime
Size: 28.39 MiB
Size change:  3.28 KiB

Package:  five-or-more-3.27.92-1.fc29
Old package:  five-or-more-3.26.0-3.fc28
Summary:  GNOME "Five or More" game
RPMs: five-or-more
Size: 9.92 MiB
Size change:  -8.99 MiB
Changelog:
  * Sun Mar 11 2018 Kalev Lember  - 3.27.92-1
  - Update to 3.27.92


Package:  fontconfig-2.13.0-2.fc29
Old package:  fontconfig-2.13.0-1.fc29
Summary:  Font configuration and customization library
RPMs: fontconfig fontconfig-devel fontconfig-devel-doc
Size: 2.96 MiB
Size change:  5.02 KiB
Changelog:
  * Mon Mar 12 2018 Akira TAGOH  - 2.13.0-2
  - Allow the const names in the range.


Package:  gcl-2.6.12-11.fc29
Old package:  gcl-2.6.12-10.fc29
Summary:  GNU Common Lisp
RPMs: gcl gcl-emacs gcl-emacs-el gcl-selinux gcl-xemacs gcl-xemacs-el
Size: 37.16 MiB
Size change:  17.20 KiB
Changelog:
  * Sat Mar 10 2018 Jerry James  - 2.6.12-11
  - The SELinux package is no arch, so drop isa from dependencies


Package:  gdm-1:3.27.92-1.fc29
Old package:  gdm-1:3.27.91-1.fc29
Summary:  The GNOME Display Manager
RPMs: gdm gdm-devel gdm-pam-extensions-devel
Size: 3.88 MiB
Size change:  6.50 KiB
Changelog:
  * Sun Mar 11 2018 Kalev Lember  - 1:3.27.92-1
  - Update to 3.27.92


Package:  gedit-plugins-3.27.92-1.fc29
Old package:  gedit-plugins-3.27.1-1.fc29
Summary:  Plugins for gedit
RPMs: gedit-plugin-bookmarks ge

Re: Gating packages in Rawhide

[Pierre-Yves Chibon]

On Mon, Mar 12, 2018 at 03:58:13PM +0100, Kevin Kofler wrote:
> Pierre-Yves Chibon wrote:
> > Do note that the uniqueness constraint that koji has will mitigate things
> > there. For a package to be built for -liba and then -libb, the package
> > will need to have its release field bumped twice.
> 
> Sure, but that has not prevented conflicts in the past either, because it 
> does not ensure that the second bump is actually built against the new 
> library for which the first bump was committed.

Thinking about this some:
package A (release 1) has two dependencies B and C.
A-2 is built in side-tag #1 for B'
A-3 is built in side-tag #2 for C'


Case #1
---
Side-tag #2 is merged, A-3 is in rawhide for C'.
Side-tag #1 is asked to be merged:
  - A-2 < A-3, so "uprade path" is not ok
  -> Merge is blocked, a new build A-4 is required
 A-4 is built against B' and C'
 --> all good


Case #2
---
Side-tag #1 is merged, A-2 is in rawhide for B'.
Side-tag #2 is asked to be merged:
  - A-3 > A-2, so "upgrade path" is ok
  -> Merge is ok, but A-3 was built against C', not B'


Solutions:
- Do not allow one package to be in two side-tags at the same time?
- Ensure the tests for Case #2 would prevent the merge (doable?)
- Figure out if between build and side-tag merge-request one of the package in
  that side tags has been part of another side-tag (definitely doable, "just" a
  little more logic)
- Another idea?


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

Re: Gating packages in Rawhide

[Pierre-Yves Chibon]

On Mon, Mar 12, 2018 at 12:48:02PM +0100, Milan Crha wrote:
>   Hi,
> 
> On Mon, 2018-03-12 at 12:10 +0100, Pierre-Yves Chibon wrote:
> > On Mon, Mar 12, 2018 at 11:33:36AM +0100, Milan Crha wrote:
> > > On Fri, 2018-03-09 at 11:35 -0800, Kevin Fenzi wrote:
> > > > Sure, with this proposal you would:
> > > > 
> > > > * request a side tag
> > > > * build a, wait for it to be added to the repo, build b, etc.
> > > > You would not need to file overrides, just build them in the
> > > > right order with wait-repo between them.
> > > 
> > Tooling can be built no? Why do you assume we can't make chain-build
> > work with side-tags?
> 
> That wasn't my suggestion, that's what Kevin Fenzi suggested and I sort
> of questioned it. :)
> 
> > Seems to me much more interesting to say: I have a few packages to
> > update, let's update them, ok I'm done, could you check if I missed
> > any? yes -> fix, no -> merge
> 
> Yes, definitely. How that "checked if I missed any" question will be
> implemented is important. It's necessary to have it done before merging
> the side tag, otherwise there will be no gain in gating at all, right?
> The best time is to have done the final check automatically when the
> merge of the side tag is requested, if I understand it correctly.

The way I envision this would be: you request the side tag to be merged, the
test will be run, report its outcome to you.
If the outcome is positive (the test passed) it will automatically merge the
tag, and otherwise it won't touch the tag, giving you the opportunity to fix the
issue.

Does that sound right?

> > The difference is that during that week, we will still be able to
> > compose rawhide tomorrow (and thus test all the other changes), while
> > we can't today.
> 
> I see, that makes perfect sense. Some packages won't stop the rest of
> the distribution. I'm only afraid people will care less when the
> problem will be in a side tag, rather than in the main stream. 

I guess that could happen, but on the other side, since the problem is isolated
in a side-tag it's not in the main stream and thus not available, even to the
people who started working on this.


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

Configuration file migration without scriptlets

[Ondřej Lysoněk]

Hi,

is there any mechanism in Fedora for config file migration? How would
you make changes to a configuration file (maybe after some config option
has been renamed), or move a config file to a new location, during
upgrade? Is there a better way than running 'sed' and 'cp' in a scriptlet?

Thanks.

Best regards
Ondřej Lysoněk
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Gating packages in Rawhide

[Kevin Kofler]

Pierre-Yves Chibon wrote:
> Do note that the uniqueness constraint that koji has will mitigate things
> there. For a package to be built for -liba and then -libb, the package
> will need to have its release field bumped twice.

Sure, but that has not prevented conflicts in the past either, because it 
does not ensure that the second bump is actually built against the new 
library for which the first bump was committed.

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

Re: Gating packages in Rawhide

[Colin Walters]

On Mon, Mar 12, 2018, at 5:32 AM, Pierre-Yves Chibon wrote:

> That would register in koji's DB the unique NEVRA which means, the PR can't be
> updated without bumping the release field.

Yep, that problem is exactly (along with the conflict-fest that is %changelog)
what holds back any big steps in making PRs-on-distgit more useful.

After removing %changelog, the next step is to make it so e.g. Koji just
auto-increments Release, or whatever.   In the end, that sort of workflow
is what everyone ends up reinventing on *top* of the existing system
in one of many versions:
https://fedoraproject.org/wiki/Layered_build_scripts_for_package_maintainers

But the PR workflow is what really brings this issue to the fore.






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

Re: unresponsive maintainer: nss-mdns

[Adam Goode]

> My FAS name is "agoode".
> 
> 
> Thanks!
This worked, thanks!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Why size of repositories metadata is too high in Fedora?

[chicago]

I've found that adding my google account to gnome online accounts makes this 
problem especially bad. Consider completely removing online accounts from gnome 
if you have any significant presence on the service (and if you don't why 
bother adding anyway?)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Gating packages in Rawhide

[Nicolas Mailhot]

Le lundi 12 mars 2018 à 14:51 +0100, Michael Šimáček a écrit :
> On 2018-03-12 12:19, Nicolas Mailhot wrote:
> > 
> > Also current chain-build is too primitive to handle complex chains
> > 
> > https://github.com/rpm-software-management/mock/issues/170
> > 
> 
> Koji chain-builds and mockchain are unrelated (both are primitive, I 
> don't disagree with that).

Yes that was mostly point to a document specifying how chain build
should be implemented to handle boostraps and make sure the result is
self-hosting.

If the rawhide workflow is going to depend on side tags and chain
builds, they better be automated, robust and correct

Regards,

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

Re: Spring cleaning my golang packages (orphaning now unused stuff)

[Nicolas Mailhot]

Le lundi 12 mars 2018 à 14:22 +0100, Fabio Valentini a écrit :
> On Mon, Mar 12, 2018 at 2:16 PM, Nicolas Mailhot
>  wrote:
> > Hi,
> > 
> > Some of those will be recreated when I submit my specs for
> > integration
> > and review but I'd rather finish stabilising the macros before I
> > submit
> > something that needs changing (some of my specs use "advanced" macro
> > features such as symlinks that are still being reworked during
> > review)
> 
> Hi Nicolas,

Hi Fabio

> I can add you too as co-admin for the relevant packages relevant to
> you, if that makes things easier for you.

If you don't mind, I'll ask at the time I try to push the spec stash.
we're still making the final tests work ,so it is possible I'll finally
end up needing a slightly different Go package list

Regards

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

Re: Gating packages in Rawhide

[Michael Šimáček]

On 2018-03-12 12:19, Nicolas Mailhot wrote:

Le 2018-03-12 12:10, Pierre-Yves Chibon a écrit :

On Mon, Mar 12, 2018 at 11:33:36AM +0100, Milan Crha wrote:

Hi,

On Fri, 2018-03-09 at 11:35 -0800, Kevin Fenzi wrote:
> Sure, with this proposal you would:
>
> * request a side tag
> * build a, wait for it to be added to the repo, build b, etc.
> You would not need to file overrides, just build them in the right
> order with wait-repo between them.

well, it's not better, it's worse. I could not just run one command and
let the computers do the task on their own, I just check from time to
time whether anything broken, but I'd be supposed to babysit whole
build process with the packages from the "chain-build"? That's truly
worse, needs more of my time, while the koji can do it on its own.
Computers are here to help people, right? :)


Tooling can be built no? Why do you assume we can't make chain-build 
work with

side-tags?


Also current chain-build is too primitive to handle complex chains

https://github.com/rpm-software-management/mock/issues/170



Koji chain-builds and mockchain are unrelated (both are primitive, I 
don't disagree with that).


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

Re: Spring cleaning my golang packages (orphaning now unused stuff)

[Fabio Valentini]

On Mon, Mar 12, 2018 at 2:16 PM, Nicolas Mailhot
 wrote:
> Hi,
>
> Some of those will be recreated when I submit my specs for integration
> and review but I'd rather finish stabilising the macros before I submit
> something that needs changing (some of my specs use "advanced" macro
> features such as symlinks that are still being reworked during review)

Hi Nicolas,

I can add you too as co-admin for the relevant packages relevant to
you, if that makes things easier for you.

Fabio

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

Re: Debugging mock error “Failed to synchronize cache for repo 'updates'”

[Michael Šimáček]

On 2018-03-09 17:47, Florian Weimer wrote:
I'm trying this, on a relatively up-to-date Fedora 27 machine 
(mock-1.4.9-1.fc27.noarch):


mock -r fedora-28-x86_64 --init

and get:

Start: dnf install
Error: Failed to synchronize cache for repo 'updates'
WARNING: Machine 00b000ffcd4543ddbe52926cee6d50d5 still running. Killing...
ERROR: Command failed:
  # /usr/bin/dnf --installroot /var/lib/mock/fedora-28-x86_64/root/ 
--releasever 28 --disableplugin=local --setopt=deltarpm=False install 
@buildsys-build

Error: Failed to synchronize cache for repo 'updates'

And that's it.   Adding -vv doesn't provide more information, e.g. which 
URL download is failing.


I tried --dnf-cmd, but the -vv for that is still processed by mock only, 
it seems.


Any suggestions?


The init step doesn't take dnf arguments, and --dnf-cmd executes the 
init step first (which fails). You can increase the dnf verbosity level 
in the configuration, e.g. change the debuglevel option in main section 
of "yum.conf" option of /etc/mock/fedora-28-x86_64.cfg


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

Re: Spring cleaning my golang packages (orphaning now unused stuff)

[Nicolas Mailhot]

Hi,

Some of those will be recreated when I submit my specs for integration
and review but I'd rather finish stabilising the macros before I submit
something that needs changing (some of my specs use "advanced" macro
features such as symlinks that are still being reworked during review)

Regards,

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

Re: Spring cleaning my golang packages (orphaning now unused stuff)

[Jan Chaloupka]

On 03/12/2018 02:13 PM, Fabio Valentini wrote:

On Mon, Mar 12, 2018 at 2:03 PM, Jan Chaloupka  wrote:

Hi Fabio,


On 03/07/2018 08:29 PM, Fabio Valentini wrote:

Hi everybody,

I'm going to orphan some of my golang packages that were initially pulled in
by syncthing as dependencies, but have been dropped as dependencies again
(... don't ask. golang people produce dependencies like rabbits make
bunnies.).

Most of them are fairly low maintenance packages, with only a few commits
per year (if even that), and decent coverage with unit tests. All of them
are up-to-date with the latest upstream git master or latest stable release,
where available, except where I have indicated otherwise.

Just write if you want to take over maintenance of one or more of these
packages, and I'll transfer ownership of the package and its dependencies.
Otherwise, I'll orphan the rest in about one week (March 14), after
re-checking that nothing depends on them anymore.


Feel free to transfer ownership of all packages you don't want to take care
of to me. Not saying I will pet them but it would be unfortunate to keep
them orphaned unless they are to be retired.

Hi Jan,


Good point. I don't think retiring the packages is necessary, since
they work fine and most upstream projects are still somewhat active.
The packages are just not used anymore (at least right now).

I can transfer ownership if you want, or I can make you co-admin and
we can take care of the packages together.
Whatever works better for you.


Co-admin will work for me :) Thanks


Fabio


Also, Athos, if you're reading this, I see that hugo is also using my
package golang-github-gobwas-glob - I can make you a co-maintainer if you
want.


Unused leaf packages:
- golang-github-AudriusButkevicius-kcp-go
- golang-github-calmh-luhn
- golang-github-ccding-go-stun
- golang-github-cznic-ql (1 commit behind git master)
- golang-github-xtaci-kcp-go

Dependencies becoming new unused leaves:
- golang-github-cznic-b
- golang-github-cznic-fileutil
- golang-github-cznic-golex
- golang-github-cznic-internal
- golang-github-cznic-lex
- golang-github-cznic-lexer
- golang-github-cznic-lldb
- golang-github-cznic-mathutil (2 commits behind git master)
- golang-github-cznic-sortutil
- golang-github-cznic-strutil
- golang-github-edsrzf-mmap-go
- golang-github-klauspost-reedsolomon
- golang-github-remyoudompheng-bigfft
- golang-github-templexxx-cpufeat
- golang-github-templexxx-reedsolomon
- golang-github-templexxx-xor
- golang-github-tjfoc-gmsm
- golang-github-xtaci-smux

Fabio


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



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


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

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

Re: Spring cleaning my golang packages (orphaning now unused stuff)

[Fabio Valentini]

On Mon, Mar 12, 2018 at 2:03 PM, Jan Chaloupka  wrote:
> Hi Fabio,
>
>
> On 03/07/2018 08:29 PM, Fabio Valentini wrote:
>
> Hi everybody,
>
> I'm going to orphan some of my golang packages that were initially pulled in
> by syncthing as dependencies, but have been dropped as dependencies again
> (... don't ask. golang people produce dependencies like rabbits make
> bunnies.).
>
> Most of them are fairly low maintenance packages, with only a few commits
> per year (if even that), and decent coverage with unit tests. All of them
> are up-to-date with the latest upstream git master or latest stable release,
> where available, except where I have indicated otherwise.
>
> Just write if you want to take over maintenance of one or more of these
> packages, and I'll transfer ownership of the package and its dependencies.
> Otherwise, I'll orphan the rest in about one week (March 14), after
> re-checking that nothing depends on them anymore.
>
>
> Feel free to transfer ownership of all packages you don't want to take care
> of to me. Not saying I will pet them but it would be unfortunate to keep
> them orphaned unless they are to be retired.

Hi Jan,


Good point. I don't think retiring the packages is necessary, since
they work fine and most upstream projects are still somewhat active.
The packages are just not used anymore (at least right now).

I can transfer ownership if you want, or I can make you co-admin and
we can take care of the packages together.
Whatever works better for you.

Fabio

> Also, Athos, if you're reading this, I see that hugo is also using my
> package golang-github-gobwas-glob - I can make you a co-maintainer if you
> want.
>
>
> Unused leaf packages:
> - golang-github-AudriusButkevicius-kcp-go
> - golang-github-calmh-luhn
> - golang-github-ccding-go-stun
> - golang-github-cznic-ql (1 commit behind git master)
> - golang-github-xtaci-kcp-go
>
> Dependencies becoming new unused leaves:
> - golang-github-cznic-b
> - golang-github-cznic-fileutil
> - golang-github-cznic-golex
> - golang-github-cznic-internal
> - golang-github-cznic-lex
> - golang-github-cznic-lexer
> - golang-github-cznic-lldb
> - golang-github-cznic-mathutil (2 commits behind git master)
> - golang-github-cznic-sortutil
> - golang-github-cznic-strutil
> - golang-github-edsrzf-mmap-go
> - golang-github-klauspost-reedsolomon
> - golang-github-remyoudompheng-bigfft
> - golang-github-templexxx-cpufeat
> - golang-github-templexxx-reedsolomon
> - golang-github-templexxx-xor
> - golang-github-tjfoc-gmsm
> - golang-github-xtaci-smux
>
> Fabio
>
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>
>
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Spring cleaning my golang packages (orphaning now unused stuff)

[Jan Chaloupka]

Hi Fabio,


On 03/07/2018 08:29 PM, Fabio Valentini wrote:

Hi everybody,

I'm going to orphan some of my golang packages that were initially 
pulled in by syncthing as dependencies, but have been dropped as 
dependencies again (... don't ask. golang people produce dependencies 
like rabbits make bunnies.).


Most of them are fairly low maintenance packages, with only a few 
commits per year (if even that), and decent coverage with unit tests. 
All of them are up-to-date with the latest upstream git master or 
latest stable release, where available, except where I have indicated 
otherwise.


Just write if you want to take over maintenance of one or more of 
these packages, and I'll transfer ownership of the package and its 
dependencies. Otherwise, I'll orphan the rest in about one week (March 
14), after re-checking that nothing depends on them anymore.




Feel free to transfer ownership of all packages you don't want to take 
care of to me. Not saying I will pet them but it would be unfortunate to 
keep them orphaned unless they are to be retired.




Also, Athos, if you're reading this, I see that hugo is also using my 
package golang-github-gobwas-glob - I can make you a co-maintainer if 
you want.



Unused leaf packages:
- golang-github-AudriusButkevicius-kcp-go
- golang-github-calmh-luhn
- golang-github-ccding-go-stun
- golang-github-cznic-ql (1 commit behind git master)
- golang-github-xtaci-kcp-go

Dependencies becoming new unused leaves:
- golang-github-cznic-b
- golang-github-cznic-fileutil
- golang-github-cznic-golex
- golang-github-cznic-internal
- golang-github-cznic-lex
- golang-github-cznic-lexer
- golang-github-cznic-lldb
- golang-github-cznic-mathutil (2 commits behind git master)
- golang-github-cznic-sortutil
- golang-github-cznic-strutil
- golang-github-edsrzf-mmap-go
- golang-github-klauspost-reedsolomon
- golang-github-remyoudompheng-bigfft
- golang-github-templexxx-cpufeat
- golang-github-templexxx-reedsolomon
- golang-github-templexxx-xor
- golang-github-tjfoc-gmsm
- golang-github-xtaci-smux

Fabio


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


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

Re: F28 System Wide Change: Replace glibc's libcrypt with libxcrypt

[Michael Schwendt]

On Fri, 9 Mar 2018 16:32:17 +0100, Florian Weimer wrote:

> GnuTLS uses Nettle, but does not provide access to DES.  You can use 
> Nettle directly:
> 
> https://www.lysator.liu.se/~nisse/nettle/nettle.html#DES
> 
> OpenSSL will work as well, but as Nettle is a preexisting dependency, 
> it's probably the right choice here.

They don't seem to be compatible.

Whereas Nettle is fully compatible with glibc's rpc/des_crypt.h API, it
offers a completely different interface than encrypt(), which operates on
arrays of 64 bytes for each 64-bit block of input.

The ciphertext returned by encrypt() differs compared with Nettle and
des_crypt (and that's with the bit vector transformation from the man page).
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Gating packages in Rawhide

[Milan Crha]

Hi,

On Mon, 2018-03-12 at 12:10 +0100, Pierre-Yves Chibon wrote:
> On Mon, Mar 12, 2018 at 11:33:36AM +0100, Milan Crha wrote:
> > On Fri, 2018-03-09 at 11:35 -0800, Kevin Fenzi wrote:
> > > Sure, with this proposal you would:
> > > 
> > > * request a side tag
> > > * build a, wait for it to be added to the repo, build b, etc.
> > > You would not need to file overrides, just build them in the
> > > right order with wait-repo between them.
> > 
> Tooling can be built no? Why do you assume we can't make chain-build
> work with side-tags?

That wasn't my suggestion, that's what Kevin Fenzi suggested and I sort
of questioned it. :)

> Seems to me much more interesting to say: I have a few packages to
> update, let's update them, ok I'm done, could you check if I missed
> any? yes -> fix, no -> merge

Yes, definitely. How that "checked if I missed any" question will be
implemented is important. It's necessary to have it done before merging
the side tag, otherwise there will be no gain in gating at all, right?
The best time is to have done the final check automatically when the
merge of the side tag is requested, if I understand it correctly.

> The idea has been submitted a few times already in this thread,...

Oh, right, I'm sorry for repeating it. My fault.

> The difference is that during that week, we will still be able to
> compose rawhide tomorrow (and thus test all the other changes), while
> we can't today.

I see, that makes perfect sense. Some packages won't stop the rest of
the distribution. I'm only afraid people will care less when the
problem will be in a side tag, rather than in the main stream. 

> Because if the packager want to push their update, they will need to
> investigate why it's not passing the tests, not infra.

Definitely, that's my point too. I'd expect it working that way
already, with or without gating. People should be responsible for
changes they do in their packages (generally speaking, I do not mean
any offense to systemd folks, not talking that I can imagine that
finding such kind of bugs is a nightmare even for the developers of the
software).

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

Re: Gating packages in Rawhide

[Milan Crha]

On Mon, 2018-03-12 at 12:12 +0100, Kalev Lember wrote:
> On 03/12/2018 11:33 AM, Milan Crha wrote:
> > I wanted to try whether chain-build with --target would make the
> > trick, it also used to work.
> 
> It should work if you use '--target f28-gnome'

Hi,
yes, I know, that's why I wrote "it also used to work". I also used to
be kicked off when trying chain-build after bodhi activation (something
about "fXX-candidate not deriving from fXX-build", but I do not recall
it precisely), which seems to be accepted right now, except after the
build of the first package the next in the chain would wait "ad
infinity" to have the first package appear in f28-build.

It's only that `koji cancel` doesn't work here (with python3, it does
when using python2), thus it took me longer to find out what to do to
stop the previous chain build, mark the one finished package with
proper tag and start the chain-build in the side tag.
Thanks and bye,
Milan
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Why size of repositories metadata is too high in Fedora?

[Ismael Olea]

On Thu, Mar 1, 2018 at 3:29 PM, Farhad Mohammadi Majd  wrote:

> Hello, in Debian (9, stable), size of all the official repositories
> metadata is maximum 10MB,
>  while in Fedora, today I ran "dnf update" for first time after installing
> Fedora 27 (Fedora-Workstation-Live-x86_64-27-1.6) and it took 20+58MB for
> two official repositories!
>
> It is really too high, why there is such difference? why don't optimize it
> and fix this problem?
>
>
In my experience, not sure if related with the described issue, I have
configured >20 repos on my laptop (12Gb RAM and several of them just one
app related) and not only dnf consumes lots of memory but gnome-software
RAM consumption grow so immense it gets unusable and stucks the machine.

Just reporting.

-- 

Ismael Olea

http://olea.org/diario/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Gating packages in Rawhide

[Nicolas Mailhot]

Le 2018-03-12 12:10, Pierre-Yves Chibon a écrit :

On Mon, Mar 12, 2018 at 11:33:36AM +0100, Milan Crha wrote:

Hi,

On Fri, 2018-03-09 at 11:35 -0800, Kevin Fenzi wrote:
> Sure, with this proposal you would:
>
> * request a side tag
> * build a, wait for it to be added to the repo, build b, etc.
> You would not need to file overrides, just build them in the right
> order with wait-repo between them.

well, it's not better, it's worse. I could not just run one command 
and

let the computers do the task on their own, I just check from time to
time whether anything broken, but I'd be supposed to babysit whole
build process with the packages from the "chain-build"? That's truly
worse, needs more of my time, while the koji can do it on its own.
Computers are here to help people, right? :)


Tooling can be built no? Why do you assume we can't make chain-build 
work with

side-tags?


Also current chain-build is too primitive to handle complex chains

https://github.com/rpm-software-management/mock/issues/170

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

Re: Gating packages in Rawhide

[Pierre-Yves Chibon]

On Sat, Mar 10, 2018 at 04:09:41AM +0100, Kevin Kofler wrote:
> Kevin Fenzi wrote:
> > yeah, but you would have even better workflow with a side tag.
> 
> The problem with a workflow relying entirely on side tags is that it is 
> going to increase the risk of conflicts with concurrent changes (a 
> phenomenon already somewhat present where side tags are used, but using side 
> tags for everything is going to make it worse).
> 
> If my package depends on liba and libb, and if we have side tags f29-liba 
> and f29-libb at the same time, when they are merged, the rebuild merged 
> later will replace the one merged earlier and we will still end up with a 
> half-broken package, or if we're lucky, the gating will fail the second 
> merge (but only if the gated merges are serialized, otherwise there is a 
> possible race condition there too).

Do note that the uniqueness constraint that koji has will mitigate things there.
For a package to be built for -liba and then -libb, the package will need to
have its release field bumped twice.

I figure it wouldn't be too hard to check when we merge a side-tag if there is a
newer build of a package already available and if so block the merge (I guess
that would be very similar to the upgrade path checks between releases, but here
it would be between koji tags).


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

Re: Gating packages in Rawhide

[Kalev Lember]

On 03/12/2018 11:33 AM, Milan Crha wrote:
> By the way, I just successfully ran chain-build from an f28 branch. 
> https://koji.fedoraproject.org/koji/taskinfo?taskID=25654934
> That surprised me, I expected to be kicked of, as it used to do, but it
> didn't do it (it used to kick me off in the past, especially after
> branching/bodhi activation point). I wanted to try whether chain-build
> with --target would make the trick, it also used to work.

It should work if you use '--target f28-gnome'

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

Re: Gating packages in Rawhide

[Pierre-Yves Chibon]

On Mon, Mar 12, 2018 at 11:33:36AM +0100, Milan Crha wrote:
>   Hi,
> 
> On Fri, 2018-03-09 at 11:35 -0800, Kevin Fenzi wrote:
> > Sure, with this proposal you would:
> > 
> > * request a side tag
> > * build a, wait for it to be added to the repo, build b, etc.
> > You would not need to file overrides, just build them in the right
> > order with wait-repo between them.
> 
> well, it's not better, it's worse. I could not just run one command and
> let the computers do the task on their own, I just check from time to
> time whether anything broken, but I'd be supposed to babysit whole
> build process with the packages from the "chain-build"? That's truly
> worse, needs more of my time, while the koji can do it on its own.
> Computers are here to help people, right? :) 

Tooling can be built no? Why do you assume we can't make chain-build work with
side-tags?
Is there a technical reason we can't just have the tool submit a build, wait for
the new repo, submit the second build and so on?
If whether this needs to be a `chain-build --side-tag=` or a `side-build
...` is up for discussion :)
 
> > I'd like to see a 'no new broken deps' test/check... but we could
> > change the tests over time.
> 
> Yeah, that's it, without such test you just make obstacles to packagers
> with no gain at all (if broken deps are recognized only after pushing
> the side tag into the Rawhide, then it's really only about unneeded
> obstacles).

The side tags would only be used if you need to update multiple packages, so
having the test run while you're in the middle of it and thus you know it's not
going to pass, seems a little useless no?
Seems to me much more interesting to say: I have a few packages to update, let's
update them, ok I'm done, could you check if I missed any?
yes -> fix, no -> merge

> > You request a side tag,
> 
> Who is going to respond to it?

The idea has been submitted a few times already in this thread, the side tags
would be managed in bodhi very much like buildroot overrides are currently.

> Will it be automated, with no specific people being involved? 

It would be automated via bodhi, likely have a rather short life by default
(exactly to avoid the race-condition issue that Kevin Kofler mentioned in
another email) but that life period could be expanded for larger rebuilds.

> (if I recall my college study properly), how you'd like to synchronize
> the process between people in various countries and time zones in
> practice, while limiting the delay to a minimum?

How would this be different from today? If it takes a week to solve a rebuild
today, the side tag tomorrow would remain open for a week.
The difference is that during that week, we will still be able to compose
rawhide tomorrow (and thus test all the other changes), while we can't today.

> > > That's also another disadvantage of the gating. I recall seeing
> > > broken dependencies messages for package I've no commit rights for
> > > for weeks.
> > 
> > Yep. Or longer.
> 
> Definitely, and it's the main point against gating Rawhide. If people
> cannot react in the timely manner right now, with already working
> infrastructure, how is the gating going to help and address this
> problem at the first place?

Because that problem will remain isolated from the rest of the distro.
So yes, as you're pointing out below some package will get a little behind and
others won't. But the formers won't prevent testing/integrating the laters.

> The gating will help to have buildable composes all the time. That's
> its main purpose, right? Then it'll help with what? What is it good for
> to have buildable composes, when they are using outdated software? All
> the QA work will be wasted on those composes, because of delay of some
> package update due to the gating.
> 
> > You could ask for commit on those packages you need commit on.
> > If those maintainers don't approve it, ask for unresponsive
> > maintainer process and you will get commit rights.
> 
> Maybe they have a reason why they want to have as less people on the
> package as they can. Or they can miss some notification from "pkgdb" (I
> know, it's not pkgdb these days) or have it lost in the spam folder...
> And it's a bad idea to expect that other people have time to work on
> Fedora just at the moment when I decide to push in some giant API

It seems to me this is even worth today. You decide a giant API change, the
other people don't have time to work on Fedora just at that moment, the entire
Fedora is stuck because things are burning.
Tomorrow: you decide a giant API change, the other people don't have time to
work on Fedora just at that moment: the rest of Fedora is happily moving
forward. Yes your change will be delayed in its integration, but it won't delay
or impact other integrations.

> change, not talking that many of the packagers just do "proxies" for
> upstream, they possibly never touched the upstream code to be able to
> fix anything in the code, thus they rely on response from the

Re: Gating packages in Rawhide

[Milan Crha]

Hi,

On Fri, 2018-03-09 at 11:35 -0800, Kevin Fenzi wrote:
> Sure, with this proposal you would:
> 
> * request a side tag
> * build a, wait for it to be added to the repo, build b, etc.
> You would not need to file overrides, just build them in the right
> order with wait-repo between them.

well, it's not better, it's worse. I could not just run one command and
let the computers do the task on their own, I just check from time to
time whether anything broken, but I'd be supposed to babysit whole
build process with the packages from the "chain-build"? That's truly
worse, needs more of my time, while the koji can do it on its own.
Computers are here to help people, right? :) 

By the way, I just successfully ran chain-build from an f28 branch. 
https://koji.fedoraproject.org/koji/taskinfo?taskID=25654934
That surprised me, I expected to be kicked of, as it used to do, but it
didn't do it (it used to kick me off in the past, especially after
branching/bodhi activation point). I wanted to try whether chain-build
with --target would make the trick, it also used to work.

> I'd like to see a 'no new broken deps' test/check... but we could
> change the tests over time.

Yeah, that's it, without such test you just make obstacles to packagers
with no gain at all (if broken deps are recognized only after pushing
the side tag into the Rawhide, then it's really only about unneeded
obstacles).

> You request a side tag,

Who is going to respond to it? Will it be automated, with no specific
people being involved? Automated side tags sound wrong, from my point
of view. Hunting for people in different timezones to let me do my duty
 sounds even worse.

> build your new package in that, then tell all the dependent package
> maintainers to use that side tag to rebuild all their packages.

Oh, having multi-process synchronization is kind of unsolvable problem
(if I recall my college study properly), how you'd like to synchronize
the process between people in various countries and time zones in
practice, while limiting the delay to a minimum?

> All those people should be watching your package or at
> least easy to communicate to.

Watching a package and/or have commit rights usually brings in tons of
unrelated stuff in your Inbox. Yes, there are settings, but I cannot
decide which changes are relevant to my package and which not unless I
read the info about the change. After some time one can just ignore
most of the messages anyway (people do lack of time, the more those
volunteers in the community).

> > That's also another disadvantage of the gating. I recall seeing
> > broken dependencies messages for package I've no commit rights for
> > for weeks.
> 
> Yep. Or longer.

Definitely, and it's the main point against gating Rawhide. If people
cannot react in the timely manner right now, with already working
infrastructure, how is the gating going to help and address this
problem at the first place?

The gating will help to have buildable composes all the time. That's
its main purpose, right? Then it'll help with what? What is it good for
to have buildable composes, when they are using outdated software? All
the QA work will be wasted on those composes, because of delay of some
package update due to the gating.

> You could ask for commit on those packages you need commit on.
> If those maintainers don't approve it, ask for unresponsive
> maintainer process and you will get commit rights.

Maybe they have a reason why they want to have as less people on the
package as they can. Or they can miss some notification from "pkgdb" (I
know, it's not pkgdb these days) or have it lost in the spam folder...
And it's a bad idea to expect that other people have time to work on
Fedora just at the moment when I decide to push in some giant API
change, not talking that many of the packagers just do "proxies" for
upstream, they possibly never touched the upstream code to be able to
fix anything in the code, thus they rely on response from the upstream,
which can add even more delay in some cases. Not talking that
unresponsive maintainer process should be started only after some time
of inactivity of the package maintainer.

> If they still don't show up, you could look at retiring those
> packages so they drop from the collection and don't bother you
> anymore.

Oh, I'd not like to go that far, for basically the same reasons as in
the previous paragraph.

> It's been a long trail of things that needed to get worked out.
> it has nothing to do with availability. A number of people have been
> spending lots of time fixing things.

I see, that's understandable. How is rawhide gating going to help with
this in practice? (Search for 'outdated software' above.) There will be
still needed some people looking into the issue and spend their time on
it, maybe they will be in less pressure, but I'm afraid it'll be just a
feeling. Nobody should expect infrastructure folks understand each
package (like you mentioned systemd here), at least I do

Re: Gating packages in Rawhide

[Pierre-Yves Chibon]

On Fri, Mar 09, 2018 at 06:48:56PM +0100, Mathieu Bridon wrote:
> On Fri, 2018-03-09 at 10:38 +0100, Pierre-Yves Chibon wrote:
> > On Fri, Mar 09, 2018 at 10:12:37AM +0100, Mathieu Bridon wrote:
> > > We could take a hint from how we make software upstream these days:
> > > 
> > > 1. submit a pull request for the package in src.fp.o on the master
> > >branch
> > > 2. a CI automatically builds this package in Koji
> > > 3. merge the pull request into master
> > > 4. the build (from step 2) is tagged for Rawhide, without a rebuild
> > > 
> > > Gating is achieved by preventing merges if the build/tests fail.
> > 
> > This has been discussed but requires a way for koji to "promote"
> > scratch builds
> > to real builds and this isn't a small task.
> > Long term, I do think this is a good idea anyway yes.
> 
> It doesn't have to be scratch builds, it could be real builds in a side
> tag.

That would register in koji's DB the unique NEVRA which means, the PR can't be
updated without bumping the release field.


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

GNOME 3.28.0 megaupdate

[Kalev Lember]

Hi all,

I'm wrangling the GNOME 3.28.0 builds in Fedora and the plan is to
submit a single megaupdate with all of 3.28.0 builds into Bodhi. If
you're helping with builds, please use 'fedpkg build --target f28-gnome'
for F28 builds and I'll pick your build up when submitting the bodhi
update later this week.

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

Re: Why size of repositories metadata is too high in Fedora?

[Pavel Raiskup]

On Friday, March 2, 2018 12:25:05 PM CET Neal Gompa wrote:
> On Fri, Mar 2, 2018 at 5:05 AM, Pavel Raiskup  wrote:
> > On Friday, March 2, 2018 2:44:19 AM CET stan wrote:
> >> On Thu, 01 Mar 2018 14:29:45 -
> >> "Farhad Mohammadi Majd"  wrote:
> >>
> >> > Hello, in Debian (9, stable), size of all the official repositories
> >> > metadata is maximum 10MB, while in Fedora, today I ran "dnf update"
> >> > for first time after installing Fedora 27
> >> > (Fedora-Workstation-Live-x86_64-27-1.6) and it took 20+58MB for two
> >> > official repositories!
> >> >
> >> > It is really too high, why there is such difference? why don't
> >> > optimize it and fix this problem?
> >>
> >> I don't have any intimate knowledge of this.  But you are comparing
> >> apples and oranges.  Apt and dnf.  Either the format of the meta data
> >> must be very different for the two, or apt must send much less meta
> >> data.
> >
> > Yes, IMO the amount of information in metadata creates the difference.
> >
> >> You aren't alone in complaining about this.  Whenever an update occurs,
> >> all the meta data has to be downloaded again.  People on limited
> >> quantity connections find this onerous.  There has been discussion of
> >> making the meta data update an incremental update, but the format of
> >> meta data doesn't lend itself well to doing this.  And the delta files
> >> would put a lot of extra files on repo hosts.
> >
> > I doubt delta files for metadata would cause significant storage problems
> > (compare that with the size of RPMs).  You don't have to keep the deltas
> > forever, it would be matter of quality of implementation..
> >
> > Do we have some RFE bug for this, or some feature page?  This is #1 issue in
> > yum/dnf world for quite some time.
> >
> 
> There's an ongoing discussion in rpm-ecosystem@[1] and
> infrastructure@[2] about an optimized delta repodata format. So...
> It's coming. :)
> 
> [1]: http://lists.rpm.org/pipermail/rpm-ecosystem/2018-February/000541.html
> [2]: 
> https://lists.fedoraproject.org/archives/list/infrastruct...@lists.fedoraproject.org/thread/4TJOGXT35Q2UHWYQA66FCCHCF5DOEXO5/

Do we already have an RFE so I could subscribe to be informed about progress?

Pavel


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

Fedora-Atomic 27-20180312.0 compose check report

[Fedora compose checker]

No missing expected images.

Passed openQA tests: 2/2 (x86_64)
-- 
Mail generated by check-compose:
https://pagure.io/fedora-qa/check-compose
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org