Re: Self Introduction: Arsenick - René Jr Purcell

[Benson Muite]

Hi,

Welcome to Fedora. There is a security lab that may also be of interest 
and worth contributing to:

https://labs.fedoraproject.org/en/security/
Qubes (https://www.qubes-os.org/) also builds ontop of Fedora as a base.

Regards,
Benson

On 03/20/2018 04:04 AM, Rene Jr Purcell wrote:
Hi everyone, I'm sending an email as suggested in the package maintainer 
documentation.


The first time I installed Linux was in 1998, since then it always has 
been in my life. I started working as a tech guy in 2000 goes to shool 
and started my professional career as a linux sysadmin in 2005.
I'm a Fedora ambassador since 2009. I was more involved at that time, 
the last 5-6 years have been crazy trying to deal with a family life, 
kids, the job, learning to work with openstack, trying new projects 
etc... So I wasn't around very often, now I'm trying to come back and 
put more time on Fedora.


I'm starting with a idea to build a spin of Fedora related to crypto, a 
kind of read-only live media where user could boot on it and interact 
with the blockchain with at the very least, the peace of mind of not 
having spyware or virus running on this OS spying it's private key. I've 
already played around with mock and built my first livecd, I have to 
package few tools that will enable to user to interact with few 
blockchains so that's why I'm here, I've packaged Myetherwallet and 
Mycrypto and I'm looking for a sponsor! I will start with tools for 
Ethereum because it's the one I'm used to work with but will slowly add 
new wallets and tools if the review process is going well with my first 
packages!


I don't know if there's a lot of "crypto enthusiast" here but I'm 
looking for ideas and I want to have discussion on how this live distro 
and packages can be achieved in the most transparent way. I'm totally 
aware the user booting this live media will put all it's trust on the 
maintainer because it could be easy to add few line of code and stole 
their private keys etc.. So I really want to do this the right way so 
the community can doublecheck everything in the process. You can join 
#MyLiveCrypto on freenode if you want to talk about that or message pm 
me, Arsenick.


Thanks, have a nice day!



___
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

Call for testing: more Fedora 28 Beta blocker-fixing updates

[Adam Williamson]

Hey folks! Just a note that there are some more F28 Beta blocker-fixing 
updates that could use some testing and feedback:

1. https://bodhi.fedoraproject.org/updates/FEDORA-2018-2c066076a2

This is an anaconda update that fixes a bug in recent versions: if you
did a live install and both created a user account and set a root
password, the root account wound up locked. You couldn't get into it.
Testing is quite easy: boot a recent live image (KDE live from a recent
F28 nightly is good), update all the anaconda packages, then run an
install, and during install, create a user account and set the root
password. Then check you can log in to the installed system as root.

2. https://bodhi.fedoraproject.org/updates/FEDORA-2018-8cff0f34f6

This FreeIPA update fixes logging into the web UI as a regular user.
Again, you can only really test this if you have or can set up a
testing FreeIPA deployment, we do not recommend upgrading production
deployments at this time.

Thanks folks!
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Link error in F28 (but not Rawhide)

[Kevin Kofler]

Kevin Fenzi wrote:
> Agreed. I think someone just needs to sit down and try and figure out
> why this is. I am not convinced (without evidence) that it's annobin or
> mini debuginfo (but of course I could be wrong).

I think there's a lot more than one or two factors at play, but if each new 
source of bloat gets waved through as "insignificant", things add up pretty 
quickly. (And global bloat such as those two "features" worries me 
particularly, though you are right that there is definitely a lot of local 
bloat at play as well.)

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

Self Introduction: Arsenick - René Jr Purcell

[Rene Jr Purcell]

Hi everyone, I'm sending an email as suggested in the package maintainer
documentation.

The first time I installed Linux was in 1998, since then it always has been
in my life. I started working as a tech guy in 2000 goes to shool and
started my professional career as a linux sysadmin in 2005.
I'm a Fedora ambassador since 2009. I was more involved at that time, the
last 5-6 years have been crazy trying to deal with a family life, kids, the
job, learning to work with openstack, trying new projects etc... So I
wasn't around very often, now I'm trying to come back and put more time on
Fedora.

I'm starting with a idea to build a spin of Fedora related to crypto, a
kind of read-only live media where user could boot on it and interact with
the blockchain with at the very least, the peace of mind of not having
spyware or virus running on this OS spying it's private key. I've already
played around with mock and built my first livecd, I have to package few
tools that will enable to user to interact with few blockchains so that's
why I'm here, I've packaged Myetherwallet and Mycrypto and I'm looking for
a sponsor! I will start with tools for Ethereum because it's the one I'm
used to work with but will slowly add new wallets and tools if the review
process is going well with my first packages!

I don't know if there's a lot of "crypto enthusiast" here but I'm looking
for ideas and I want to have discussion on how this live distro and
packages can be achieved in the most transparent way. I'm totally aware the
user booting this live media will put all it's trust on the maintainer
because it could be easy to add few line of code and stole their private
keys etc.. So I really want to do this the right way so the community can
doublecheck everything in the process. You can join #MyLiveCrypto on
freenode if you want to talk about that or message pm me, Arsenick.

Thanks, have a nice day!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

[Fedocal] Reminder meeting : Modularity WG (once every two weeks)

[jkurik]

Dear all,

You are kindly invited to the meeting:
   Modularity WG (once every two weeks) on 2018-03-20 from 10:00:00 to 11:00:00 
US/Eastern
   At fedora-meetin...@irc.freenode.net

The meeting will be about:
Meeting of the Modularity Working Group.

More information available at: [Modularity Working Group wiki 
page](https://fedoraproject.org/wiki/Modularity_Working_Group)

The agenda for the meeting is available at [modularity-wg-agendas 
pad](https://board.net/p/modularity-wg-agendas).



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

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

Re: Lorax has changed groups on github: rhinstaller -> weldr

[chicago]

Congrats on a successful migration and thank you for supporting https on the 
documentation
 
https://weldr.io/lorax/


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Lorax has changed groups on github: rhinstaller -> weldr

[Brian C. Lane]

I've just completed moving Lorax over to the weldr group on github.com
The new location is:

https://github.com/weldr/lorax
(github will forward you to the new location if you visit the
rhinstaller one)

All issues and PRs have be preserved in the move.

You can update git to point to the new location like so:

git remote set-url origin g...@github.com:weldr/lorax.git

Docs are now hosted here:

http://weldr.io/lorax/

(sadly github doesn't forward the old docs location to the new one)

If you have any problems, or find something I've forgotten to update
please let me know.

-- 
Brian C. Lane (PST8PDT)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Using the Fedora infra for crypto-mining

[Zachary Snyder]

Yeah kevin,

not much of it even seems possible let alone plausible.



Github: https://github.com/Sadin | Pagure: https://pagure.io/user/sadin |
Twitter: https://twitter.com/sadinzs | Mastodon:
https://mastodon.social/@sadinzs

On Mon, Mar 19, 2018 at 4:17 PM, Kevin Fenzi  wrote:

> On 03/19/2018 01:08 PM, Zachary Snyder wrote:
> > I feel like if this were going on there are multiple eyes on the machines
> > that support FAS and the infra.
> > Personally I don't think it is a concern. CPU hashing doesn't even report
> > successes because of
> > blockchain difficultly, In any coin that matters.
> >
> > Not a bad thing to bring up though, so that maybe now more eyes can be
> wary
> > of it going forward.
> >
> > Github: https://github.com/Sadin | Pagure: https://pagure.io/user/sadin
> |
> > Twitter: https://twitter.com/sadinzs | Mastodon:
> > https://mastodon.social/@sadinzs
>
> Sure, we will keep an eye out, but I don't see this as too likely.
>
> I'm not by any means an expert on crypto-mining, but I suspect for many
> of them you need a internet connection (which is lacking in koji and
> copr unless you know to turn the option on), additionally I think at
> least for bitcoin, mining with "normal" CPU's is not even worth the time
> to setup... you need a vast pile of GPUs or ASICs these days, and even
> then you need many orders of magnitude more nodes than we have koji
> builders or copr builders.
>
> Anyhow, thanks for the heads up, will keep watch for them.
>
> kevin
>
>
>
> ___
> 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: Using the Fedora infra for crypto-mining

[Kevin Fenzi]

On 03/19/2018 01:08 PM, Zachary Snyder wrote:
> I feel like if this were going on there are multiple eyes on the machines
> that support FAS and the infra.
> Personally I don't think it is a concern. CPU hashing doesn't even report
> successes because of
> blockchain difficultly, In any coin that matters.
> 
> Not a bad thing to bring up though, so that maybe now more eyes can be wary
> of it going forward.
> 
> Github: https://github.com/Sadin | Pagure: https://pagure.io/user/sadin |
> Twitter: https://twitter.com/sadinzs | Mastodon:
> https://mastodon.social/@sadinzs

Sure, we will keep an eye out, but I don't see this as too likely.

I'm not by any means an expert on crypto-mining, but I suspect for many
of them you need a internet connection (which is lacking in koji and
copr unless you know to turn the option on), additionally I think at
least for bitcoin, mining with "normal" CPU's is not even worth the time
to setup... you need a vast pile of GPUs or ASICs these days, and even
then you need many orders of magnitude more nodes than we have koji
builders or copr builders.

Anyhow, thanks for the heads up, will keep watch for them.

kevin




signature.asc
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Using the Fedora infra for crypto-mining

[Zachary Snyder]

I feel like if this were going on there are multiple eyes on the machines
that support FAS and the infra.
Personally I don't think it is a concern. CPU hashing doesn't even report
successes because of
blockchain difficultly, In any coin that matters.

Not a bad thing to bring up though, so that maybe now more eyes can be wary
of it going forward.

Github: https://github.com/Sadin | Pagure: https://pagure.io/user/sadin |
Twitter: https://twitter.com/sadinzs | Mastodon:
https://mastodon.social/@sadinzs

On Mon, Mar 19, 2018 at 4:01 PM, Dridi Boukelmoune <
dridi.boukelmo...@gmail.com> wrote:

> > To be completely clear here, crypto-mining is not a valid use of Fedora
> > Project resources. Hopefully our community realizes and respects this.
>
> To be completely clear here (just in case it was misinterpreted=) I
> was expressing my concern. I'm not worried about our community but it
> is my understanding that you can (ab)use free computing with just a
> FAS account.
>
> Dridi
> ___
> 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: Using the Fedora infra for crypto-mining

[Dridi Boukelmoune]

> To be completely clear here, crypto-mining is not a valid use of Fedora
> Project resources. Hopefully our community realizes and respects this.

To be completely clear here (just in case it was misinterpreted=) I
was expressing my concern. I'm not worried about our community but it
is my understanding that you can (ab)use free computing with just a
FAS account.

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

Fedora 28-20180319.n.0 compose check report

[Fedora compose checker]

No missing expected images.

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

ID: 207446  Test: x86_64 Server-dvd-iso server_realmd_join_kickstart
URL: https://openqa.fedoraproject.org/tests/207446
ID: 207482  Test: i386 Workstation-boot-iso memory_check
URL: https://openqa.fedoraproject.org/tests/207482
ID: 207483  Test: i386 Workstation-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/207483
ID: 207484  Test: x86_64 KDE-live-iso desktop_notifications_live
URL: https://openqa.fedoraproject.org/tests/207484
ID: 207485  Test: x86_64 KDE-live-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/207485
ID: 207497  Test: arm Minimal-raw_xz-raw.xz 
install_arm_image_deployment_upload
URL: https://openqa.fedoraproject.org/tests/207497
ID: 207501  Test: x86_64 AtomicWorkstation-dvd_ostree-iso 
install_default_upload
URL: https://openqa.fedoraproject.org/tests/207501
ID: 207502  Test: x86_64 AtomicWorkstation-dvd_ostree-iso 
install_default@uefi
URL: https://openqa.fedoraproject.org/tests/207502
ID: 207503  Test: x86_64 AtomicWorkstation-dvd_ostree-iso install_no_user
URL: https://openqa.fedoraproject.org/tests/207503
ID: 207516  Test: x86_64 universal install_cyrillic_language
URL: https://openqa.fedoraproject.org/tests/207516
ID: 207550  Test: x86_64 universal upgrade_server_domain_controller
URL: https://openqa.fedoraproject.org/tests/207550
ID: 207563  Test: x86_64 universal install_package_set_kde
URL: https://openqa.fedoraproject.org/tests/207563
ID: 207589  Test: i386 universal install_simple_encrypted
URL: https://openqa.fedoraproject.org/tests/207589
ID: 207597  Test: i386 universal upgrade_2_desktop_32bit
URL: https://openqa.fedoraproject.org/tests/207597
ID: 207598  Test: i386 universal install_package_set_kde
URL: https://openqa.fedoraproject.org/tests/207598
ID: 207625  Test: x86_64 KDE-live-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/207625

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

ID: 207460  Test: i386 Server-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/207460
ID: 207461  Test: i386 Server-dvd-iso install_default
URL: https://openqa.fedoraproject.org/tests/207461
ID: 207477  Test: x86_64 Workstation-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/207477
ID: 207480  Test: x86_64 Workstation-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/207480
ID: 207481  Test: i386 Workstation-live-iso install_default
URL: https://openqa.fedoraproject.org/tests/207481
ID: 207526  Test: x86_64 universal install_asian_language
URL: https://openqa.fedoraproject.org/tests/207526
ID: 207552  Test: x86_64 universal upgrade_kde_64bit
URL: https://openqa.fedoraproject.org/tests/207552
ID: 207554  Test: x86_64 universal upgrade_2_minimal_64bit
URL: https://openqa.fedoraproject.org/tests/207554
ID: 207574  Test: x86_64 universal install_iscsi
URL: https://openqa.fedoraproject.org/tests/207574
ID: 207577  Test: x86_64 universal upgrade_2_server_64bit
URL: https://openqa.fedoraproject.org/tests/207577

Passed openQA tests: 104/137 (x86_64), 15/23 (i386)

Skipped openQA tests: 16 of 162
-- 
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

Re: What to do when test gating in bodhi fails (no test results found)?

[Adam Williamson]

On Mon, 2018-03-19 at 15:57 +0100, Pierre-Yves Chibon wrote:
> On Mon, Mar 19, 2018 at 03:41:15PM +0100, Dan Horák wrote:
> > On Mon, 19 Mar 2018 14:06:56 +0100
> > Dan Horák  wrote:
> > 
> > > On Sun, 18 Mar 2018 20:25:31 +0100
> > > Fabio Valentini  wrote:
> > > 
> > > > On Sun, Mar 18, 2018 at 7:13 PM, Michael Cronenworth
> > > >  wrote:
> > > > > On 03/18/2018 01:02 PM, Fabio Valentini wrote:
> > > > > > 
> > > > > > I've looked at waiverdb-cli too, but since no tests seem to have
> > > > > > run at all, it looks like the wrong tool for the job:
> > > > > > I don't want to push an update despite a failed test, I want to
> > > > > > push my update despite no test data being available ...
> > > > > 
> > > > > 
> > > > > Randy said the tests refresh every 6 hours and/or every time the
> > > > > update is edited. Neither seemed to have occurred for you.
> > > > 
> > > > Exactly. The "no test results found" status in bodhi hasn't been
> > > > refreshed in over 10 days now.
> > > > 
> > > > Bodhi also displays that all these tests were successful, bit still
> > > > blocks the update because "no test results found", which is
> > > > obviously just wrong.
> > > > 
> > > > A manual lookup in resultdb shows me that the tests have in fact
> > > > been run and have all passed:
> > > 
> > > https://bodhi.fedoraproject.org/updates/FEDORA-2018-200708ae05 is in
> > > the same situation, all tests are green, but "no test results found"
> > > is reported. It's not very user friendly ...
> > 
> > and https://bodhi.fedoraproject.org/updates/FEDORA-2018-71350d90a7 is
> > even more interesting with "The update can not be pushed: 1 of 2
> > required tests not found", but the listed tests are again all green. No
> > idea what's missing from the output.
> 
> All the tests can be green if the "important" ones are missing, they don't 
> show
> :(
> 
> The important ones are the ones defined in the policy that gates packages and
> are listed here: https://fedoraproject.org/wiki/CI/gating_updates
> 
> waiverdb-cli should now support waiving missing results, I'm double-checking 
> it
> and see if we can document it at:
> https://fedoraproject.org/wiki/Package_update_HOWTO#Handling_feedback_from_automated_tests
> next to the other examples.

It is also still the case that unpushing and re-pushing the update
should re-trigger the tests in Taskotron, at the cost of re-setting the
karma and 'wait time' clocks for the update (so you'll need to either
get positive karma or wait 7 or 14 days before being able to push it,
from the time of the re-push).

One obvious easy win here would be to change the "No test results
found" text, as it's clearly confusing. It could be something like "No
results found for blocking tests", perhaps? We could even give Bodhi
the ability to list the names of the 'expected' blocking tests, and
have the text show that somehow, whether as a hyperlink or perhaps just
as a mouseover or something?
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Goodbye nvr.rsplit('-', 2), hello modularity

[Jan Kaluza]

On Mon, Mar 19, 2018 at 4:43 PM, Adam Williamson  wrote:

> On Mon, 2018-03-19 at 10:58 +0100, Stanislav Ochotnicky wrote:
> > On Mon 19 Mar 2018 09:38:58 AM GMT Fabio Valentini wrote:
> > > So you think having to send a request to a web service instead of just
> > > parsing a string locally with one line of code is a good trade-off for
> > > allowing dashes?
> >
> > This has been mentioned several times in this thread and I think there's
> > a misunderstanding around this.
> >
> > So: When your tool/whatever works with modules it will have to have
> > module metadata available in some form.
>
> What if I don't want to work with modules at all, just with information
> about modules?
>
> What if I just want to write a tool that parses fedmsgs about module
> builds in Koji and does something that depends on module names, streams
> and versions? (e.g. some sort of changelog thing)
>

Your tool can use good old buildsys.build.state.change fedmsg with the well
known name/version/release fields like this:

https://apps.stg.fedoraproject.org/datagrepper/raw?topic=org.fedoraproject.stg.buildsys.build.state.change

That's staging, because it's easier for me to find the module builds there
:).

Unfortunatelly, Koji does not add "type" field there, so you cannot find
out if that's module or not. But in case your tool is doing general
changelog per Koji build, it will work quite well with modules without you
even noticing you are working with modules.

In case of tools, you can even query koji using its api and pass the
name/version/release there, instead of NVR.

If you query Koji for the module build, you will actually find whole module
metadata in "extra" part of the build.

In case you are OK with using MBS fedmsgs, you can use the fedmsgs Nils
already sent in this thread.

Regards,
Jan Kaluza

--
> Adam Williamson
> Fedora QA Community Monkey
> IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
> http://www.happyassassin.net
> ___
> 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: Using the Fedora infra for crypto-mining

[Martin Kolman]

On Mon, 2018-03-19 at 18:16 +, Jonathan Wakely wrote:
> On 19/03/18 16:38 +0100, Michal Novotny wrote:
> > Builds are being automatically terminated if not finished in 18 hours.
> > The virtual machines that builds run on are also not particularly strong
> > so if anyone tried to mine something by this method, he wouldn't
> > get particularly rich :).
> 
> *Any* return is profit when you don't pay for the hardware, hosting or
> electricity. That's why unscrupulous people abuse free services.
Sure, but they will still have some costs of their own:
- setting the whole thing up on their end
- generating accounts (possibly manual process) as old ones get banned
- running the "orchestrator" that pushes the mining jobs to unsuspecting public 
infrastructure
- any obfuscation and detection avoidence they would have to do

As long as the these costs are bigger than their "yield" they won't get any 
actual
profit and will likely not bother (or more probably will move somewhere else).

> ___
> 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: Using the Fedora infra for crypto-mining

[Jonathan Wakely]

On 19/03/18 16:38 +0100, Michal Novotny wrote:

Builds are being automatically terminated if not finished in 18 hours.
The virtual machines that builds run on are also not particularly strong
so if anyone tried to mine something by this method, he wouldn't
get particularly rich :).


*Any* return is profit when you don't pay for the hardware, hosting or
electricity. That's why unscrupulous people abuse free services.
___
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'

[Jonathan Wakely]

On 17/03/18 16:51 +0100, René Genz wrote:

Thanks to Jonathan, Athos, and Tom for the discussion.
I added one of Tom's links and pushed the text:
https://fedoraproject.org/wiki/Join_the_package_collection_maintainers#One-off_contributions


Thanks!

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

Re: What to do when test gating in bodhi fails (no test results found)?

[Julian Sikorski]

W dniu 19.03.2018 o 15:57, Pierre-Yves Chibon pisze:
> On Mon, Mar 19, 2018 at 03:41:15PM +0100, Dan Horák wrote:
>> On Mon, 19 Mar 2018 14:06:56 +0100
>> Dan Horák  wrote:
>>
>>> On Sun, 18 Mar 2018 20:25:31 +0100
>>> Fabio Valentini  wrote:
>>>
 On Sun, Mar 18, 2018 at 7:13 PM, Michael Cronenworth
  wrote:
> On 03/18/2018 01:02 PM, Fabio Valentini wrote:
>>
>> I've looked at waiverdb-cli too, but since no tests seem to have
>> run at all, it looks like the wrong tool for the job:
>> I don't want to push an update despite a failed test, I want to
>> push my update despite no test data being available ...
>
>
> Randy said the tests refresh every 6 hours and/or every time the
> update is edited. Neither seemed to have occurred for you.

 Exactly. The "no test results found" status in bodhi hasn't been
 refreshed in over 10 days now.

 Bodhi also displays that all these tests were successful, bit still
 blocks the update because "no test results found", which is
 obviously just wrong.

 A manual lookup in resultdb shows me that the tests have in fact
 been run and have all passed:
>>>
>>> https://bodhi.fedoraproject.org/updates/FEDORA-2018-200708ae05 is in
>>> the same situation, all tests are green, but "no test results found"
>>> is reported. It's not very user friendly ...
>>
>> and https://bodhi.fedoraproject.org/updates/FEDORA-2018-71350d90a7 is
>> even more interesting with "The update can not be pushed: 1 of 2
>> required tests not found", but the listed tests are again all green. No
>> idea what's missing from the output.
> 
> All the tests can be green if the "important" ones are missing, they don't 
> show
> :(
> 
> The important ones are the ones defined in the policy that gates packages and
> are listed here: https://fedoraproject.org/wiki/CI/gating_updates
> 
> waiverdb-cli should now support waiving missing results, I'm double-checking 
> it
> and see if we can document it at:
> https://fedoraproject.org/wiki/Package_update_HOWTO#Handling_feedback_from_automated_tests
> next to the other examples.
> 
> 
> 
> Pierre

For the 4 [1-4] updates of mine which are affected, dist.abicheck has
passed but for some reason dist.rpmdeplint results are not shown in
bodhi - any ideas why this might be?

Best regards,
Julian

[1] https://bodhi.fedoraproject.org/updates/FEDORA-2018-53b8c6ce1a
[2] https://bodhi.fedoraproject.org/updates/FEDORA-2018-d22393ae23
[3] https://bodhi.fedoraproject.org/updates/FEDORA-2018-0948ce3cc4
[4] https://bodhi.fedoraproject.org/updates/FEDORA-2018-0efad2f5b4

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

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

[Yaakov Selkowitz]

On 2018-02-18 11:09, Igor Gnatenko wrote:
> Over this weekend I've performed scratch-mass-rebuild without having gcc and
> gcc-c++ in buildroot of all Fedora packages, many of which failed due to 
> random
> reasons and I grepped all logs for some common errors found by analyzing
> hundreds of build logs.
> 
> Some packages might be missed due to short koji outage, broken dependencies 
> and
> so on, but majority of real failures is below.
> 
> If you fixed package(s), found false positive, found missing packages in list
> or anything else -- please let me know.

Fixed: lame latex2rtf libpsl notification-daemon ttfautohint
xcf-pixbuf-loader

-- 
Yaakov Selkowitz
Software Engineer - Platform Enablement Group
Red Hat, Inc.



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: 20180319.n.0 changes

[Fedora Branched Report]

OLD: Fedora-28-20180318.n.0
NEW: Fedora-28-20180319.n.0

= SUMMARY =
Added images:1
Dropped images:  3
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: Container_Minimal_Base docker s390x
Path: 
Container/s390x/images/Fedora-Container-Minimal-Base-28-20180319.n.0.s390x.tar.xz

= DROPPED IMAGES =
Image: Container_Base docker s390x
Path: Container/s390x/images/Fedora-Container-Base-28-20180318.n.0.s390x.tar.xz
Image: AtomicHost qcow2 aarch64
Path: AtomicHost/aarch64/images/Fedora-AtomicHost-28-20180318.n.0.aarch64.qcow2
Image: AtomicHost raw-xz aarch64
Path: AtomicHost/aarch64/images/Fedora-AtomicHost-28-20180318.n.0.aarch64.raw.xz

= ADDED PACKAGES =

= DROPPED PACKAGES =

= UPGRADED PACKAGES =

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

Re: Goodbye nvr.rsplit('-', 2), hello modularity

[Adam Williamson]

On Mon, 2018-03-19 at 17:18 +0100, Nils Philippsen wrote:
> On Mon, 2018-03-19 at 08:43 -0700, Adam Williamson wrote:
> > What if I just want to write a tool that parses fedmsgs about module
> > builds in Koji and does something that depends on module names,
> > streams
> > and versions? (e.g. some sort of changelog thing)
> 
> I haven't looked at actual fedmsgs lately but they should carry this
> information as separate fields, e.g. here's how a module state change
> message is specified:
> 
> https://fedora-fedmsg.readthedocs.io/en/latest/topics.html#mbs-module-state-change
> 
> The `context` field is missing here but I guess that's just a case of
> the docs not keeping up with the latest changes.

Ah, that is useful. Thanks.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Using the Fedora infra for crypto-mining

[Kevin Fenzi]

On 03/19/2018 08:38 AM, Michal Novotny wrote:
> Hello Dridi,
> 
> On Mon, Mar 19, 2018 at 10:13 AM, Dridi Boukelmoune
>  wrote:
>> Hello list,
>>
>> Since I work on a project that uses the Coverity Scan free plan for
>> open source software it came to my attention today that free scans
>> were put on hold and resumed recently because people were abusing it
>> for crypto mining.
>>
>> Since I couldn't find any discussion on this list around this topic I
>> figured I could start one, if only to ask whether this is a
>> possibility for Fedora. If I'm not mistaken you don't need much more
>> than a FAS account to host COPR repositories and run builds.
>>
>> Could someone abuse the infra in such a way?
> 
> Builds are being automatically terminated if not finished in 18 hours.
> The virtual machines that builds run on are also not particularly strong
> so if anyone tried to mine something by this method, he wouldn't
> get particularly rich :).
> 
> Also, we would probably find out because of long-running builds
> are easy to discover thanks to the public build queue (it is also not
> like we would be running 1000 builds at once, then it would be hard
> to track).
> 
> So I wouldn't be really worried about this.

koji also has a timeout.

To be completely clear here, crypto-mining is not a valid use of Fedora
Project resources. Hopefully our community realizes and respects this.

If it becomes a problem we would of course have to spend some time in
detection and killing such processes, but I hope it doesn't come to that.

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: Goodbye nvr.rsplit('-', 2), hello modularity

[Nils Philippsen]

On Mon, 2018-03-19 at 08:43 -0700, Adam Williamson wrote:
> What if I just want to write a tool that parses fedmsgs about module
> builds in Koji and does something that depends on module names,
> streams
> and versions? (e.g. some sort of changelog thing)

I haven't looked at actual fedmsgs lately but they should carry this
information as separate fields, e.g. here's how a module state change
message is specified:

https://fedora-fedmsg.readthedocs.io/en/latest/topics.html#mbs-module-state-change

The `context` field is missing here but I guess that's just a case of
the docs not keeping up with the latest changes.

Nils
-- 
Nils Philippsen"Those who would give up Essential Liberty to
Software Engineer   purchase a little Temporary Safety, deserve neither
Red Hat Liberty nor Safety."  --  Benjamin Franklin, 1759
PGP fingerprint:C4A8 9474 5C4C ADE3 2B8F  656D 47D8 9B65 6951 3011
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Request for testing: dbus-broker as system and user bus

[Zbigniew Jędrzejewski-Szmek]

On Mon, Mar 19, 2018 at 11:42:57AM +0100, Vít Ondruch wrote:
> I would like to test it, but as long as it keeps the original dbus on my
> system, I won't install it. I don't want two dbus implementations on my
> system.
That's a bit harsh, especially in the testing phase.
/usr/bin/dbus-daemon is 231k, so if it's not running, it hardly
matters. Long-term, the plan is of course to install just one implementation
by default.

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

Re: Link error in F28 (but not Rawhide)

[Kevin Fenzi]

On 03/16/2018 05:11 PM, Adam Williamson wrote:
> 
> The compile error is fixed, but the packages didn't magically get
> smaller.
> 
> I really kinda agree with Kevin, FWIW. The images have got
> *significantly* bigger across the last few releases and we're just
> sorta shrugging and going 'ok, whatever'. I keep seeing pushes to spin-
> kickstarts to make image sizes bigger for no particular reason except
> just 'stuff bloated', that's kinda sad.
> 
> It's not really about whether things fit on a CD or not, it's about not
> needlessly wasting bandwidth and storage space. If the packages are
> bigger then they take up more space on our hard disks, USB sticks, on
> mirrors, they take more time to transfer, and we *do* still have users
> on slow and bandwidth-limited connections.

Agreed. I think someone just needs to sit down and try and figure out
why this is. I am not convinced (without evidence) that it's annobin or
mini debuginfo (but of course I could be wrong).

I can add this to my list, but not sure when I would get to it.
Hopefully we will figure out the why, then we can look at how to fix it.

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 Rawhide-20180319.n.0 compose check report

[Fedora compose checker]

No missing expected images.

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

ID: 207283  Test: x86_64 Server-dvd-iso server_role_deploy_domain_controller
URL: https://openqa.fedoraproject.org/tests/207283
ID: 207312  Test: x86_64 Workstation-live-iso desktop_update_graphical
URL: https://openqa.fedoraproject.org/tests/207312
ID: 207317  Test: x86_64 Workstation-boot-iso memory_check@uefi
URL: https://openqa.fedoraproject.org/tests/207317
ID: 207320  Test: i386 Workstation-boot-iso memory_check
URL: https://openqa.fedoraproject.org/tests/207320
ID: 207321  Test: i386 Workstation-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/207321
ID: 207322  Test: x86_64 KDE-live-iso desktop_notifications_live
URL: https://openqa.fedoraproject.org/tests/207322
ID: 207327  Test: x86_64 KDE-live-iso install_no_user
URL: https://openqa.fedoraproject.org/tests/207327
ID: 207335  Test: arm Minimal-raw_xz-raw.xz 
install_arm_image_deployment_upload
URL: https://openqa.fedoraproject.org/tests/207335
ID: 207339  Test: x86_64 AtomicWorkstation-dvd_ostree-iso 
install_default_upload
URL: https://openqa.fedoraproject.org/tests/207339
ID: 207340  Test: x86_64 AtomicWorkstation-dvd_ostree-iso 
install_default@uefi
URL: https://openqa.fedoraproject.org/tests/207340
ID: 207341  Test: x86_64 AtomicWorkstation-dvd_ostree-iso install_no_user
URL: https://openqa.fedoraproject.org/tests/207341
ID: 207381  Test: x86_64 universal upgrade_2_kde_64bit
URL: https://openqa.fedoraproject.org/tests/207381
ID: 207382  Test: x86_64 universal upgrade_2_desktop_encrypted_64bit
URL: https://openqa.fedoraproject.org/tests/207382
ID: 207388  Test: x86_64 universal upgrade_server_domain_controller
URL: https://openqa.fedoraproject.org/tests/207388
ID: 207392  Test: x86_64 universal upgrade_2_minimal_64bit
URL: https://openqa.fedoraproject.org/tests/207392
ID: 207393  Test: x86_64 universal upgrade_2_desktop_64bit
URL: https://openqa.fedoraproject.org/tests/207393
ID: 207400  Test: x86_64 universal install_delete_pata@uefi
URL: https://openqa.fedoraproject.org/tests/207400
ID: 207401  Test: x86_64 universal install_package_set_kde
URL: https://openqa.fedoraproject.org/tests/207401
ID: 207415  Test: x86_64 universal upgrade_2_server_64bit
URL: https://openqa.fedoraproject.org/tests/207415
ID: 207427  Test: i386 universal install_simple_encrypted
URL: https://openqa.fedoraproject.org/tests/207427
ID: 207435  Test: i386 universal upgrade_2_desktop_32bit
URL: https://openqa.fedoraproject.org/tests/207435
ID: 207436  Test: i386 universal install_package_set_kde
URL: https://openqa.fedoraproject.org/tests/207436

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

ID: 207298  Test: i386 Server-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/207298
ID: 207299  Test: i386 Server-dvd-iso install_default
URL: https://openqa.fedoraproject.org/tests/207299
ID: 207304  Test: x86_64 Workstation-live-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/207304
ID: 207305  Test: x86_64 Workstation-live-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/207305
ID: 207315  Test: x86_64 Workstation-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/207315
ID: 207318  Test: x86_64 Workstation-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/207318
ID: 207319  Test: i386 Workstation-live-iso install_default
URL: https://openqa.fedoraproject.org/tests/207319
ID: 207364  Test: x86_64 universal install_asian_language
URL: https://openqa.fedoraproject.org/tests/207364
ID: 207391  Test: x86_64 universal upgrade_desktop_encrypted_64bit
URL: https://openqa.fedoraproject.org/tests/207391
ID: 207419  Test: x86_64 universal upgrade_desktop_64bit
URL: https://openqa.fedoraproject.org/tests/207419
ID: 207434  Test: i386 universal upgrade_desktop_32bit
URL: https://openqa.fedoraproject.org/tests/207434

Passed openQA tests: 104/137 (x86_64), 14/23 (i386)

Skipped openQA tests: 9 of 162
-- 
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

Re: Goodbye nvr.rsplit('-', 2), hello modularity

[Adam Williamson]

On Mon, 2018-03-19 at 10:58 +0100, Stanislav Ochotnicky wrote:
> On Mon 19 Mar 2018 09:38:58 AM GMT Fabio Valentini wrote:
> > So you think having to send a request to a web service instead of just
> > parsing a string locally with one line of code is a good trade-off for
> > allowing dashes?
> 
> This has been mentioned several times in this thread and I think there's
> a misunderstanding around this.
> 
> So: When your tool/whatever works with modules it will have to have
> module metadata available in some form.

What if I don't want to work with modules at all, just with information
about modules?

What if I just want to write a tool that parses fedmsgs about module
builds in Koji and does something that depends on module names, streams
and versions? (e.g. some sort of changelog thing)
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Using the Fedora infra for crypto-mining

[Michal Novotny]

Hello Dridi,

On Mon, Mar 19, 2018 at 10:13 AM, Dridi Boukelmoune
 wrote:
> Hello list,
>
> Since I work on a project that uses the Coverity Scan free plan for
> open source software it came to my attention today that free scans
> were put on hold and resumed recently because people were abusing it
> for crypto mining.
>
> Since I couldn't find any discussion on this list around this topic I
> figured I could start one, if only to ask whether this is a
> possibility for Fedora. If I'm not mistaken you don't need much more
> than a FAS account to host COPR repositories and run builds.
>
> Could someone abuse the infra in such a way?

Builds are being automatically terminated if not finished in 18 hours.
The virtual machines that builds run on are also not particularly strong
so if anyone tried to mine something by this method, he wouldn't
get particularly rich :).

Also, we would probably find out because of long-running builds
are easy to discover thanks to the public build queue (it is also not
like we would be running 1000 builds at once, then it would be hard
to track).

So I wouldn't be really worried about this.

Best regards
clime

>
> Cheers,
> Dridi
> ___
> 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: Goodbye nvr.rsplit('-', 2), hello modularity

[Adam Williamson]

On Mon, 2018-03-19 at 09:27 +0100, Petr Šabata wrote:
> This, AFAIK, only affects what you see in some parts of the
> build and update system (and on the bus).

That's a very important parenthesis, as we as a project do a lot of
work with fedmsg messages.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: What to do when test gating in bodhi fails (no test results found)?

[Pierre-Yves Chibon]

On Mon, Mar 19, 2018 at 03:41:15PM +0100, Dan Horák wrote:
> On Mon, 19 Mar 2018 14:06:56 +0100
> Dan Horák  wrote:
> 
> > On Sun, 18 Mar 2018 20:25:31 +0100
> > Fabio Valentini  wrote:
> > 
> > > On Sun, Mar 18, 2018 at 7:13 PM, Michael Cronenworth
> > >  wrote:
> > > > On 03/18/2018 01:02 PM, Fabio Valentini wrote:
> > > >>
> > > >> I've looked at waiverdb-cli too, but since no tests seem to have
> > > >> run at all, it looks like the wrong tool for the job:
> > > >> I don't want to push an update despite a failed test, I want to
> > > >> push my update despite no test data being available ...
> > > >
> > > >
> > > > Randy said the tests refresh every 6 hours and/or every time the
> > > > update is edited. Neither seemed to have occurred for you.
> > > 
> > > Exactly. The "no test results found" status in bodhi hasn't been
> > > refreshed in over 10 days now.
> > > 
> > > Bodhi also displays that all these tests were successful, bit still
> > > blocks the update because "no test results found", which is
> > > obviously just wrong.
> > > 
> > > A manual lookup in resultdb shows me that the tests have in fact
> > > been run and have all passed:
> > 
> > https://bodhi.fedoraproject.org/updates/FEDORA-2018-200708ae05 is in
> > the same situation, all tests are green, but "no test results found"
> > is reported. It's not very user friendly ...
> 
> and https://bodhi.fedoraproject.org/updates/FEDORA-2018-71350d90a7 is
> even more interesting with "The update can not be pushed: 1 of 2
> required tests not found", but the listed tests are again all green. No
> idea what's missing from the output.

All the tests can be green if the "important" ones are missing, they don't show
:(

The important ones are the ones defined in the policy that gates packages and
are listed here: https://fedoraproject.org/wiki/CI/gating_updates

waiverdb-cli should now support waiving missing results, I'm double-checking it
and see if we can document it at:
https://fedoraproject.org/wiki/Package_update_HOWTO#Handling_feedback_from_automated_tests
next to the other examples.



Pierre

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

Re: What to do when test gating in bodhi fails (no test results found)?

[Dan Horák]

On Mon, 19 Mar 2018 14:06:56 +0100
Dan Horák  wrote:

> On Sun, 18 Mar 2018 20:25:31 +0100
> Fabio Valentini  wrote:
> 
> > On Sun, Mar 18, 2018 at 7:13 PM, Michael Cronenworth
> >  wrote:
> > > On 03/18/2018 01:02 PM, Fabio Valentini wrote:
> > >>
> > >> I've looked at waiverdb-cli too, but since no tests seem to have
> > >> run at all, it looks like the wrong tool for the job:
> > >> I don't want to push an update despite a failed test, I want to
> > >> push my update despite no test data being available ...
> > >
> > >
> > > Randy said the tests refresh every 6 hours and/or every time the
> > > update is edited. Neither seemed to have occurred for you.
> > 
> > Exactly. The "no test results found" status in bodhi hasn't been
> > refreshed in over 10 days now.
> > 
> > Bodhi also displays that all these tests were successful, bit still
> > blocks the update because "no test results found", which is
> > obviously just wrong.
> > 
> > A manual lookup in resultdb shows me that the tests have in fact
> > been run and have all passed:
> 
> https://bodhi.fedoraproject.org/updates/FEDORA-2018-200708ae05 is in
> the same situation, all tests are green, but "no test results found"
> is reported. It's not very user friendly ...

and https://bodhi.fedoraproject.org/updates/FEDORA-2018-71350d90a7 is
even more interesting with "The update can not be pushed: 1 of 2
required tests not found", but the listed tests are again all green. No
idea what's missing from the output.


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

Fedora rawhide compose report: 20180319.n.0 changes

[Fedora Rawhide Report]

OLD: Fedora-Rawhide-20180318.n.0
NEW: Fedora-Rawhide-20180319.n.0

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

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

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

= ADDED IMAGES =

= DROPPED IMAGES =
Image: Container_Base docker s390x
Path: 
Container/s390x/images/Fedora-Container-Base-Rawhide-20180318.n.0.s390x.tar.xz

= ADDED PACKAGES =

= DROPPED PACKAGES =

= UPGRADED PACKAGES =
Package:  NetworkManager-ssh-1.2.7-4.fc29
Old package:  NetworkManager-ssh-1.2.7-3.fc29
Summary:  NetworkManager VPN plugin for SSH
RPMs: NetworkManager-ssh NetworkManager-ssh-gnome
Size: 724.80 KiB
Size change:  1012 B
Changelog:
  * Sun Mar 18 2018 Lubomir Rintel  - 1.2.7-4
  - Do not drag in the connection editor


Package:  R-V8-1.5-4.fc29
Old package:  R-V8-1.5-3.fc29
Summary:  Embedded JavaScript Engine for R
RPMs: R-V8
Size: 1.29 MiB
Size change:  588 B
Changelog:
  * Sun Mar 18 2018 Elliott Sales de Andrade  - 1.5-4
  - Add missing Rcpp Requires


Package:  R-gdtools-0.1.7-2.fc29
Old package:  R-gdtools-0.1.7-1.fc29
Summary:  Utilities for Graphical Rendering
RPMs: R-gdtools R-gdtools-devel
Size: 916.11 KiB
Size change:  1.62 KiB
Changelog:
  * Sun Mar 18 2018 Elliott Sales de Andrade  - 
0.1.7-2
  - Add missing Rcpp Requires.


Package:  R-lubridate-1.7.3-4.fc29
Old package:  R-lubridate-1.7.3-3.fc29
Summary:  Make dealing with dates a little easier
RPMs: R-lubridate
Size: 5.53 MiB
Size change:  964 B
Changelog:
  * Sun Mar 18 2018 Elliott Sales de Andrade  - 
1.7.3-4
  - Add missing Rcpp Requires.
  - Make library name explicit.


Package:  R-reshape2-1.4.3-3.fc29
Old package:  R-reshape2-1.4.3-2.fc29
Summary:  Flexibly Reshape Data: A Reboot of the Reshape Package
RPMs: R-reshape2
Size: 771.41 KiB
Size change:  1.04 KiB
Changelog:
  * Sun Mar 18 2018 Elliott Sales de Andrade  - 
1.4.3-3
  - Add missing Rcpp Require.


Package:  R-xml2-1.2.0-3.fc29
Old package:  R-xml2-1.2.0-2.fc28
Summary:  Parse XML
RPMs: R-xml2 R-xml2-devel
Size: 1.64 MiB
Size change:  2.77 KiB
Changelog:
  * Sun Mar 18 2018 Elliott Sales de Andrade  - 
1.1.1-4
  - Add missing Rcpp Requires.

  * Sun Mar 18 2018 Elliott Sales de Andrade  - 
1.2.0-3
  - Add missing Rcpp Requires.
  - Make library path explicit.


Package:  arm-trusted-firmware-1.5-0.4.rc3.fc29
Old package:  arm-trusted-firmware-1.5-0.3.rc2.fc29
Summary:  ARM Trusted Firmware
RPMs: arm-trusted-firmware-armv8
Size: 102.29 KiB
Size change:  504 B
Changelog:
  * Sun Mar 18 2018 Peter Robinson  1.5-0.4-rc3
  - New 1.5 rc3 release


Package:  clover2-3.7.4-1.D20180310git9f2ef3a.fc29
Old package:  clover2-3.7.2-1.D20180307git35659ca.fc29
Summary:  Yet another compiler language
RPMs: clover2
Size: 2.26 MiB
Size change:  9.00 KiB
Changelog:
  * Sun Mar 18 2018 Mamoru TASAKA  - 
3.7.4-1.D20180310git9f2ef3a
  - 3.7.4


Package:  deepin-wm-1.9.21-3.fc29
Old package:  deepin-wm-1.9.21-3.fc28
Summary:  Deepin Window Manager
RPMs: deepin-wm deepin-wm-devel
Size: 2.91 MiB
Size change:  -1.96 KiB

Package:  fts-rest-3.6.3-6.fc29
Old package:  fts-rest-3.4.0-2.fc25
Summary:  FTS3 Rest Interface
RPMs: fts-rest fts-rest-cli fts-rest-cloud-storage 
fts-rest-http-authz-signed-cert fts-rest-oauth2 fts-rest-selinux python2-fts
Added RPMs:   python2-fts
Dropped RPMs: python-fts
Size: 372.50 KiB
Size change:  -53.62 KiB
Changelog:
  * Tue Nov 15 2016 Alejandro Alvarez Ayllon  - 3.5.4-1
  - Update for new upstream release

  * Fri Feb 10 2017 Fedora Release Engineering  - 
3.5.4-2
  - Rebuilt for https://fedoraproject.org/wiki/Fedora_26_Mass_Rebuild

  * Tue Apr 18 2017 Alejandro Alvarez Ayllon  - 3.6.3-1
  - Update for new upstream release

  * Wed Jul 26 2017 Fedora Release Engineering  - 
3.6.3-2
  - Rebuilt for https://fedoraproject.org/wiki/Fedora_27_Mass_Rebuild

  * Sat Aug 19 2017 Zbigniew J??drzejewski-Szmek  - 3.6.3-3
  - Python 2 binary package renamed to python2-fts-rest
See https://fedoraproject.org/wiki/FinalizingFedoraSwitchtoPython3

  * Sun Dec 17 2017 Zbigniew J??drzejewski-Szmek 
  - Python 2 binary package renamed to python2-fts
See https://fedoraproject.org/wiki/FinalizingFedoraSwitchtoPython3

  * Wed Feb 07 2018 Fedora Release Engineering 
  - Rebuilt for https://fedoraproject.org/wiki/Fedora_28_Mass_Rebuild


Package:  gap-pkg-carat-2.2.1-1.fc29
Old package:  gap-pkg-carat-2.1.7-2.fc28
Summary:  GAP interface to CARAT
RPMs: gap-pkg-carat
Size: 177.70 KiB
Size change:  -1.05 KiB
Changelog

Re: Best way to handle sub-package conflicts

[Michael Schwendt]

On Sun, 18 Mar 2018 12:44:37 -0400, Digimer wrote:

>   I think "Conflict" is the way to go. However, given how much the guide
> urges not to use 'Conflicts', I worry that will make it
> harder/impossible later to have the package accepted into Fedora.
> 
>   Would a use-case like this be an acceptable exception, would you guess?
> 
>   As I mentioned in my reply to Micheal, I am not worried about
> auto-removal. If it simply refused to install one sub-package until the
> other is gone, that's fine.

There are runtime solutions, such as using "alternatives", which you may
need to use to get such packages accepted into the Fedora package
collection.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: What to do when test gating in bodhi fails (no test results found)?

[Dan Horák]

On Sun, 18 Mar 2018 20:25:31 +0100
Fabio Valentini  wrote:

> On Sun, Mar 18, 2018 at 7:13 PM, Michael Cronenworth
>  wrote:
> > On 03/18/2018 01:02 PM, Fabio Valentini wrote:
> >>
> >> I've looked at waiverdb-cli too, but since no tests seem to have
> >> run at all, it looks like the wrong tool for the job:
> >> I don't want to push an update despite a failed test, I want to
> >> push my update despite no test data being available ...
> >
> >
> > Randy said the tests refresh every 6 hours and/or every time the
> > update is edited. Neither seemed to have occurred for you.
> 
> Exactly. The "no test results found" status in bodhi hasn't been
> refreshed in over 10 days now.
> 
> Bodhi also displays that all these tests were successful, bit still
> blocks the update because "no test results found", which is obviously
> just wrong.
> 
> A manual lookup in resultdb shows me that the tests have in fact been
> run and have all passed:

https://bodhi.fedoraproject.org/updates/FEDORA-2018-200708ae05 is in
the same situation, all tests are green, but "no test results found" is
reported. It's not very user friendly ...


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

Re: Goodbye nvr.rsplit('-', 2), hello modularity

[Pierre-Yves Chibon]

On Mon, Mar 19, 2018 at 10:10:23AM +0100, Jan Kaluza wrote:
>If something does not support modules and it should support modules and
>*needs* to work with Koji content-generator imported builds for some
>reason, it needs to updated to support modules and as part of this update,
>it can be told to use ':' as its output.
> 
>If something does support modules already, it needs to be updated to
>support "context" field anyway and as part of this update ... ^
> 
>Note that this is just about the "module" type koji builds imported to
>Koji by MBS once the module is built. I think that t if you have no idea
>that those builds exist, you have nothing to update in your tool.
> 
>What is impacted by this is:
>- Bodhi - which is easy to update and I've sent a PR which has been
>continued on by Patrick and is merged now.
>- Pungi - this supports ":" already.
>- MBS, pdc-updater - supports ":" already.
>Is there actually anything else?

This is precisely what scared me a little bit with this change. We have a very
limited knowledge of what it will break.
You noted here the major things it impacts, I would not be entirely surprised
if there would be more we're missing atm and there are definitively high chances
that there are tooling out there that we do not control that is going to break.

That things break is one thing, that Patrick is the one announcing it because he
learned about this the hard way while trying to make a crucial infra tool work
with module is something different (and I'm not even going to ask the question
of why Patrick is the one working on this).


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

Re: Request for testing: dbus-broker as system and user bus

[Vít Ondruch]

I would like to test it, but as long as it keeps the original dbus on my
system, I won't install it. I don't want two dbus implementations on my
system.


Vít


Dne 13.3.2018 v 15:04 Tom Gundersen napsal(a):
> Hi,
>
> dbus-broker is a new DBus message bus implementation. We are proposing
> it as the default in Fedora as of F29 [0], and as such we would be
> grateful for as much testing as possible before the switch is made.
>
> For instructions on how to test, see [1].
>
> Cheers,
>
> Tom and David
>
> [0]: 
> 
> [1]: 
> 
> ___
> 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: Goodbye nvr.rsplit('-', 2), hello modularity

[Stanislav Ochotnicky]

On Mon 19 Mar 2018 09:38:58 AM GMT Fabio Valentini wrote:
> So you think having to send a request to a web service instead of just
> parsing a string locally with one line of code is a good trade-off for
> allowing dashes?

This has been mentioned several times in this thread and I think there's
a misunderstanding around this.

So: When your tool/whatever works with modules it will have to have
module metadata available in some form. In most client-side tools, I'd
guess that will be modulemd metadata in dnf repositories that will get
synced locally (just like rpm/yum repodata). Or it really might be
you'll query koji for the metadata if needed on a system without local
dnf metadata. But if you're working on top of module repositories -
metadata will be there.

RPMs *in* modules still use "N-V-R.A" strings and you can keep parsing
them. That is not changing. But the module that contains them uses
different strategy that allows maintainers more flexibility. And there
does not have to be exact match between module/stream etc name and NVRs
of rpms inside as others have mentioned.


-- 
Stanislav Ochotnicky 
Software Engineer, PnT DevOps - Brno

PGP: F434 2286 27DC 7D9B 2B64  0866 BCBD 752E 7B08 7241
Red Hat Inc.   http://www.redhat.com
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Goodbye nvr.rsplit('-', 2), hello modularity

[Fabio Valentini]

On Mon, Mar 19, 2018, 10:20 Petr Šabata  wrote:

> On Mon, Mar 19, 2018 at 08:57:08AM +, Zbigniew Jędrzejewski-Szmek
> wrote:
> > On Mon, Mar 19, 2018 at 09:27:30AM +0100, Petr Šabata wrote:
> > > On Sun, Mar 18, 2018 at 07:09:23PM +, Zbigniew Jędrzejewski-Szmek
> wrote:
> > > > On Fri, Mar 16, 2018 at 04:14:27PM -0400, Randy Barlow wrote:
> > > > > On 03/16/2018 04:04 PM, Dennis Gregorovic wrote:
> > > > > > modules are not RPMs.  I would not expect them to necessarily
> use the
> > > > > > same format as RPMs.  If we take koji out of the equation, we
> have
> > > > > > module builds in N:S:V:C format and module RPMs in N-V-R.A
> format.  They
> > > > > > use different separators, but both can be parsed consistently.
> > > > >
> > > > > I don't contest the above, but I am arguing that it is needlessly
> > > > > different and causes infrastructure software to need to handle
> module
> > > > > strings differently than they handle RPMs and containers. Perhaps
> there
> > > > > is a benefit that I've not been made aware of yet, but from where
> I sit
> > > > > it seems like a change that causes problems without bringing a
> tangible
> > > > > benefit.
> > > > >
> > > > > The reasoning I've heard so far is that this allows stream names
> to have
> > > > > -'s in them - is that important? I don't know it to be, but am
> open to
> > > > > be convinced. Thus my question - is it important enough to have
> -'s in
> > > > > stream names to justify the work needed to make all things that
> interact
> > > > > with Koji parse them using a web service rather than local code
> (such as
> > > > > rsplit('-', 2) in Python)?
> > > >
> > > > So, is anyone knowledgeable who can answer this question?
> > > >
> > > > If nobody can, then mostly likely the answer is "no, it's not
> important".
> > >
> > > The reason for allowing hyphens was to, maybe ironically, allow
> > > more flexibility and to avoid unnecessary restriction on names.
> > >
> > > While streams are often presented as upstream versions in
> > > most of the examples, they're strings and are, in reality, an
> > > extension to the name.  Your stream might be just "6" or "8" but
> > > it could also be "experimental-build" or "performance-patches".
> > > Current tooling shortcomings shouldn't influence how details
> > > like this are designed.  The tooling can be fixed (or enhanced,
> > > if you prefer).
> > Thank you for the detailed reply.
> >
> > I see the reasons, and the elegance of not placing restrictions on the
> > stream field, but I think that's one of those where practicality beats
> > purity. _Tooling_ may be improved, but this is also about _humans_.
> > With the current format, it is simply impossible to look at a module
> > n-s-v-c string and parse it into components. In other words, it's not
> > possible to say what the *name* is. This is a major practical issue.
>
> We would really prefer people looking at the structured data
> rather than the imperfect string when processing modules.
> Modules carry quite a lot of it; strings are just identifiers.
> I know it's tempting but doing so might produce suboptimal
> results.  That said, if people here (or FESCo) feel like decoding
> ID strings is crucial, another policy limiting the options in
> Fedora might always be added.  I'd say it'd be unfortunate, though.
>
> > Frankly, I don't think it's a big restriction to forbid dashes in
> > stream name. Colons, semicolons, slashes, spaces, and a host of other
> > characters have to be forbidden too. If we establish a convention to
> > use plus, underscore, dot, or whatever is the most appropriate, in
> > a few months people will not remember why they ever wanted dashes.
>
> Yes, but unlike all of the examples above, dashes are
> comparatively more common as word delimeters in this context and
> I think is the most natural choice.  New rules and conventions
> can be defined, of course, but it's still forcing people to
> work around ambiguous technological limitations.
>
> P
>

So you think having to send a request to a web service instead of just
parsing a string locally with one line of code is a good trade-off for
allowing dashes?

Gaining one additional allowed character and therefore losing the ability
to parse this locally just seems mad to me ... compared to that,
introducing a "convention" of using underscores (or sth. else) as word
delimiters within fields looks more reasonable by multiple orders of
magnitude ...

Just my 2c.

Fabio

> Zbyszek
> >
> > > The ordering of the fields is based on the importance of
> > > the field to the user and most of them are optional when
> > > people interact with modules using their package manager.
> > > "module", "module:stream", "module:stream:version" are all
> > > valid inputs (we do not expect people to use context directly;
> > > it's just serialized that distinguishes individual builds for
> > > stream expansion).  Context is indeed similar to dist-tag,
> > > just richer.  Given the parallel availability

Re: Goodbye nvr.rsplit('-', 2), hello modularity

[Petr Šabata]

On Mon, Mar 19, 2018 at 08:57:08AM +, Zbigniew Jędrzejewski-Szmek wrote:
> On Mon, Mar 19, 2018 at 09:27:30AM +0100, Petr Šabata wrote:
> > On Sun, Mar 18, 2018 at 07:09:23PM +, Zbigniew Jędrzejewski-Szmek wrote:
> > > On Fri, Mar 16, 2018 at 04:14:27PM -0400, Randy Barlow wrote:
> > > > On 03/16/2018 04:04 PM, Dennis Gregorovic wrote:
> > > > > modules are not RPMs.  I would not expect them to necessarily use the
> > > > > same format as RPMs.  If we take koji out of the equation, we have
> > > > > module builds in N:S:V:C format and module RPMs in N-V-R.A format.  
> > > > > They
> > > > > use different separators, but both can be parsed consistently. 
> > > > 
> > > > I don't contest the above, but I am arguing that it is needlessly
> > > > different and causes infrastructure software to need to handle module
> > > > strings differently than they handle RPMs and containers. Perhaps there
> > > > is a benefit that I've not been made aware of yet, but from where I sit
> > > > it seems like a change that causes problems without bringing a tangible
> > > > benefit.
> > > > 
> > > > The reasoning I've heard so far is that this allows stream names to have
> > > > -'s in them - is that important? I don't know it to be, but am open to
> > > > be convinced. Thus my question - is it important enough to have -'s in
> > > > stream names to justify the work needed to make all things that interact
> > > > with Koji parse them using a web service rather than local code (such as
> > > > rsplit('-', 2) in Python)?
> > > 
> > > So, is anyone knowledgeable who can answer this question?
> > > 
> > > If nobody can, then mostly likely the answer is "no, it's not important".
> > 
> > The reason for allowing hyphens was to, maybe ironically, allow
> > more flexibility and to avoid unnecessary restriction on names.
> >
> > While streams are often presented as upstream versions in
> > most of the examples, they're strings and are, in reality, an
> > extension to the name.  Your stream might be just "6" or "8" but
> > it could also be "experimental-build" or "performance-patches".
> > Current tooling shortcomings shouldn't influence how details
> > like this are designed.  The tooling can be fixed (or enhanced,
> > if you prefer).
> Thank you for the detailed reply.
> 
> I see the reasons, and the elegance of not placing restrictions on the
> stream field, but I think that's one of those where practicality beats
> purity. _Tooling_ may be improved, but this is also about _humans_.
> With the current format, it is simply impossible to look at a module
> n-s-v-c string and parse it into components. In other words, it's not
> possible to say what the *name* is. This is a major practical issue.

We would really prefer people looking at the structured data
rather than the imperfect string when processing modules.
Modules carry quite a lot of it; strings are just identifiers.
I know it's tempting but doing so might produce suboptimal
results.  That said, if people here (or FESCo) feel like decoding
ID strings is crucial, another policy limiting the options in
Fedora might always be added.  I'd say it'd be unfortunate, though.

> Frankly, I don't think it's a big restriction to forbid dashes in
> stream name. Colons, semicolons, slashes, spaces, and a host of other
> characters have to be forbidden too. If we establish a convention to
> use plus, underscore, dot, or whatever is the most appropriate, in
> a few months people will not remember why they ever wanted dashes.

Yes, but unlike all of the examples above, dashes are
comparatively more common as word delimeters in this context and
I think is the most natural choice.  New rules and conventions
can be defined, of course, but it's still forcing people to
work around ambiguous technological limitations.

P

> 
> Zbyszek
> 
> > The ordering of the fields is based on the importance of
> > the field to the user and most of them are optional when
> > people interact with modules using their package manager.
> > "module", "module:stream", "module:stream:version" are all
> > valid inputs (we do not expect people to use context directly;
> > it's just serialized that distinguishes individual builds for
> > stream expansion).  Context is indeed similar to dist-tag,
> > just richer.  Given the parallel availability, your modules
> > aren't built just for a release of Fedora, they are built for
> > any valid combination of their modular dependncies, with the
> > Fedora release being just one of them.
> > 
> > Note, as Patrick's already said, these names do not leak
> > anywhere.  Modules are not RPMs and are not handled as such.
> > This, AFAIK, only affects what you see in some parts of the
> > build and update system (and on the bus).
> > 
> > Also note that generally if you have access to modules, you
> > have access to their (structured) metadata.
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email t

Using the Fedora infra for crypto-mining

[Dridi Boukelmoune]

Hello list,

Since I work on a project that uses the Coverity Scan free plan for
open source software it came to my attention today that free scans
were put on hold and resumed recently because people were abusing it
for crypto mining.

Since I couldn't find any discussion on this list around this topic I
figured I could start one, if only to ask whether this is a
possibility for Fedora. If I'm not mistaken you don't need much more
than a FAS account to host COPR repositories and run builds.

Could someone abuse the infra in such a way?

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

Re: Goodbye nvr.rsplit('-', 2), hello modularity

[Jan Kaluza]

On Sat, Mar 17, 2018 at 4:15 PM, Patrick マルタインアンドレアス Uiterwijk <
puiterw...@redhat.com> wrote:

> > Don't be afraid of koji. :)
>
> I couldn't agree more, Koji's a pretty nice project to work on.
> It might seems scary for newcomers because of all the ingrained knowledge
> and assumptions, but once you get close the community is nice and friendly
> :).
>
> >
> > It is under active development.  Of course, resources are limited and not
> > everything can be taken on, but it's worth having the discussion.  I have
> > filed https://pagure.io/koji/issue/851 as a strawman and will try to
> > solicit feedback on the idea.
> >
>
> Thanks for doing that, though I don't know that it would resolve my
> challenges.
> First, I'd like to point out that by now I've basically solved the
> problems for Bodhi and know how to deal with this change.
> The main reason I wanted to send this email is because in things like
> fedmsg's and other things, the NVRs as imported by Koji still leak out.
> Even if the identifiers are colon-separated in all places and the N-S-V
> encoded version is never exported out of koji, people will still need to
> update scripts and tooling, and bringing that to people's attention was my
> main reason for sending the email.
>
> I absolutely did not mean for my email to be judgemental, as I've not been
> privy to the decision to allow dashes in multiple fields or the rest, so I
> can't really judge the reasoning or the conclusion.
> If it came over as judging, I'm sorry, I really just wanted to give people
> a headsup so that they have some upfront time to update scripts before
> seeing eithe module identifiers in fedmsg's or any other place.
>
> > Patrick, if https://pagure.io/koji/issue/851 was implemented would that
> > resolve the challenge you were facing?  If not, it might be worth
> reaching
> > out to koji-devel(a)lists.fedorahosted.org and discussing it further
> there.
>
> It would not, but that's okay.
> It would still mean that Module identifiers, whether you notice them as
> N-S-V.C or N:S:V:C, are new, and all tooling and scripts will need to be
> updated to handle those new identifiers.
>

I've read some parts of this thread and I see people are kind of saying "we
have to update all the tooling". I really don't think there is tooling
which needs to be updated *just* because of the delimiter.

If something does not support modules and it should support modules and
*needs* to work with Koji content-generator imported builds for some
reason, it needs to updated to support modules and as part of this update,
it can be told to use ':' as its output.

If something does support modules already, it needs to be updated to
support "context" field anyway and as part of this update ... ^

Note that this is just about the "module" type koji builds imported to Koji
by MBS once the module is built. I think that t if you have no idea that
those builds exist, you have nothing to update in your tool.

What is impacted by this is:
- Bodhi - which is easy to update and I've sent a PR which has been
continued on by Patrick and is merged now.
- Pungi - this supports ":" already.
- MBS, pdc-updater - supports ":" already.

Is there actually anything else?

Regards,
Jan Kaluza


> >
> > Cheers
> > -- Dennis
>
> Patrick
> ___
> 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: Goodbye nvr.rsplit('-', 2), hello modularity

[Zbigniew Jędrzejewski-Szmek]

On Mon, Mar 19, 2018 at 09:27:30AM +0100, Petr Šabata wrote:
> On Sun, Mar 18, 2018 at 07:09:23PM +, Zbigniew Jędrzejewski-Szmek wrote:
> > On Fri, Mar 16, 2018 at 04:14:27PM -0400, Randy Barlow wrote:
> > > On 03/16/2018 04:04 PM, Dennis Gregorovic wrote:
> > > > modules are not RPMs.  I would not expect them to necessarily use the
> > > > same format as RPMs.  If we take koji out of the equation, we have
> > > > module builds in N:S:V:C format and module RPMs in N-V-R.A format.  They
> > > > use different separators, but both can be parsed consistently. 
> > > 
> > > I don't contest the above, but I am arguing that it is needlessly
> > > different and causes infrastructure software to need to handle module
> > > strings differently than they handle RPMs and containers. Perhaps there
> > > is a benefit that I've not been made aware of yet, but from where I sit
> > > it seems like a change that causes problems without bringing a tangible
> > > benefit.
> > > 
> > > The reasoning I've heard so far is that this allows stream names to have
> > > -'s in them - is that important? I don't know it to be, but am open to
> > > be convinced. Thus my question - is it important enough to have -'s in
> > > stream names to justify the work needed to make all things that interact
> > > with Koji parse them using a web service rather than local code (such as
> > > rsplit('-', 2) in Python)?
> > 
> > So, is anyone knowledgeable who can answer this question?
> > 
> > If nobody can, then mostly likely the answer is "no, it's not important".
> 
> The reason for allowing hyphens was to, maybe ironically, allow
> more flexibility and to avoid unnecessary restriction on names.
>
> While streams are often presented as upstream versions in
> most of the examples, they're strings and are, in reality, an
> extension to the name.  Your stream might be just "6" or "8" but
> it could also be "experimental-build" or "performance-patches".
> Current tooling shortcomings shouldn't influence how details
> like this are designed.  The tooling can be fixed (or enhanced,
> if you prefer).
Thank you for the detailed reply.

I see the reasons, and the elegance of not placing restrictions on the
stream field, but I think that's one of those where practicality beats
purity. _Tooling_ may be improved, but this is also about _humans_.
With the current format, it is simply impossible to look at a module
n-s-v-c string and parse it into components. In other words, it's not
possible to say what the *name* is. This is a major practical issue.

Frankly, I don't think it's a big restriction to forbid dashes in
stream name. Colons, semicolons, slashes, spaces, and a host of other
characters have to be forbidden too. If we establish a convention to
use plus, underscore, dot, or whatever is the most appropriate, in
a few months people will not remember why they ever wanted dashes.

Zbyszek

> The ordering of the fields is based on the importance of
> the field to the user and most of them are optional when
> people interact with modules using their package manager.
> "module", "module:stream", "module:stream:version" are all
> valid inputs (we do not expect people to use context directly;
> it's just serialized that distinguishes individual builds for
> stream expansion).  Context is indeed similar to dist-tag,
> just richer.  Given the parallel availability, your modules
> aren't built just for a release of Fedora, they are built for
> any valid combination of their modular dependncies, with the
> Fedora release being just one of them.
> 
> Note, as Patrick's already said, these names do not leak
> anywhere.  Modules are not RPMs and are not handled as such.
> This, AFAIK, only affects what you see in some parts of the
> build and update system (and on the bus).
> 
> Also note that generally if you have access to modules, you
> have access to their (structured) metadata.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Goodbye nvr.rsplit('-', 2), hello modularity

[Adam Samalik]

(a repost from the infra list)


Please note that modules (and therefore module builds) may reference to
multiple RPM builds. Also, the module name doesn't need to match any RPM
name. Therefore getting package names from the module build name would not
be possible anyway.


As an exapmple, see the following build: https://koji.fedoraproject.
org/koji/buildinfo?buildID=1057280

Build name: "golang-ecosystem-2017.0-20180312141905.40a0ab3e"

If you open the modulemd [1] (a module definition file) linked at the
bottom of the page, you'll see that this module build contains four RPM
components (SRPMs):
 * golang-github-russross-blackfriday
 * go-srpm-macros
 * golang-github-cpuguy83-go-md2man
 * go-compilers

The page also says "Package Namegolang-ecosystem" which links to a
"golang-ecosystem" package [2] in Koji. That's weird, there is no such
package named "golang-ecosystem". The page lists two module builds, not two
package builds.


Another example, where a module references only one RPM package and the
module name matches the package name: https://koji.fedoraproject.
org/koji/buildinfo?buildID=1055922

Build name: "nodejs-6-20180308155546.c2c572ec"

Here, the modulemd [3] lists just one RPM component (SRPM):
 * nodejs

The page also says "Package Namenodejs" which again links to a "nodejs"
package [4] in Koji. But this time, there *is* a "nodejs" package as well
as a "nodejs" module. That page lists both!

An example of a "nodejs" package [5], build name
"nodejs-9.8.0-1.module_1571+4f4bc63d" which is a good old NVR.

An example of a "nodejs" module [6], build name
"nodejs-6-20180308155546.c2c572ec"
whic is not an NVR, it's a NSVC (name, stream, version, context).


So after going through these two examples, I think this discussion should
be more about:
 1. storing two completely different IDs (NVR and NSVC) in the same data
structure
 2. listing two different build types (package and module) in the same
place, both as package builds



[1] https://kojipkgs.fedoraproject.org//packages/golang-ecosystem/2017.0/
20180312141905.40a0ab3e/files/module/modulemd.txt
[2] https://koji.fedoraproject.org/koji/packageinfo?packageID=25886
[3] https://kojipkgs.fedoraproject.org//packages/nodejs/6/20180308155546.
c2c572ec/files/module/modulemd.txt
[4] https://koji.fedoraproject.org/koji/packageinfo?packageID=15154
[5] https://koji.fedoraproject.org/koji/buildinfo?buildID=1055873
[6] https://koji.fedoraproject.org/koji/buildinfo?buildID=1055927


On Mon, Mar 19, 2018 at 9:27 AM, Petr Šabata  wrote:

> On Sun, Mar 18, 2018 at 07:09:23PM +, Zbigniew Jędrzejewski-Szmek
> wrote:
> > On Fri, Mar 16, 2018 at 04:14:27PM -0400, Randy Barlow wrote:
> > > On 03/16/2018 04:04 PM, Dennis Gregorovic wrote:
> > > > modules are not RPMs.  I would not expect them to necessarily use the
> > > > same format as RPMs.  If we take koji out of the equation, we have
> > > > module builds in N:S:V:C format and module RPMs in N-V-R.A format.
> They
> > > > use different separators, but both can be parsed consistently.
> > >
> > > I don't contest the above, but I am arguing that it is needlessly
> > > different and causes infrastructure software to need to handle module
> > > strings differently than they handle RPMs and containers. Perhaps there
> > > is a benefit that I've not been made aware of yet, but from where I sit
> > > it seems like a change that causes problems without bringing a tangible
> > > benefit.
> > >
> > > The reasoning I've heard so far is that this allows stream names to
> have
> > > -'s in them - is that important? I don't know it to be, but am open to
> > > be convinced. Thus my question - is it important enough to have -'s in
> > > stream names to justify the work needed to make all things that
> interact
> > > with Koji parse them using a web service rather than local code (such
> as
> > > rsplit('-', 2) in Python)?
> >
> > So, is anyone knowledgeable who can answer this question?
> >
> > If nobody can, then mostly likely the answer is "no, it's not important".
>
> The reason for allowing hyphens was to, maybe ironically, allow
> more flexibility and to avoid unnecessary restriction on names.
>
> While streams are often presented as upstream versions in
> most of the examples, they're strings and are, in reality, an
> extension to the name.  Your stream might be just "6" or "8" but
> it could also be "experimental-build" or "performance-patches".
> Current tooling shortcomings shouldn't influence how details
> like this are designed.  The tooling can be fixed (or enhanced,
> if you prefer).
>
> The ordering of the fields is based on the importance of
> the field to the user and most of them are optional when
> people interact with modules using their package manager.
> "module", "module:stream", "module:stream:version" are all
> valid inputs (we do not expect people to use context directly;
> it's just serialized that distinguishes individual builds for
> stream expansion).  Context is indeed similar to dist-tag

Re: Goodbye nvr.rsplit('-', 2), hello modularity

[Petr Šabata]

On Sun, Mar 18, 2018 at 07:09:23PM +, Zbigniew Jędrzejewski-Szmek wrote:
> On Fri, Mar 16, 2018 at 04:14:27PM -0400, Randy Barlow wrote:
> > On 03/16/2018 04:04 PM, Dennis Gregorovic wrote:
> > > modules are not RPMs.  I would not expect them to necessarily use the
> > > same format as RPMs.  If we take koji out of the equation, we have
> > > module builds in N:S:V:C format and module RPMs in N-V-R.A format.  They
> > > use different separators, but both can be parsed consistently. 
> > 
> > I don't contest the above, but I am arguing that it is needlessly
> > different and causes infrastructure software to need to handle module
> > strings differently than they handle RPMs and containers. Perhaps there
> > is a benefit that I've not been made aware of yet, but from where I sit
> > it seems like a change that causes problems without bringing a tangible
> > benefit.
> > 
> > The reasoning I've heard so far is that this allows stream names to have
> > -'s in them - is that important? I don't know it to be, but am open to
> > be convinced. Thus my question - is it important enough to have -'s in
> > stream names to justify the work needed to make all things that interact
> > with Koji parse them using a web service rather than local code (such as
> > rsplit('-', 2) in Python)?
> 
> So, is anyone knowledgeable who can answer this question?
> 
> If nobody can, then mostly likely the answer is "no, it's not important".

The reason for allowing hyphens was to, maybe ironically, allow
more flexibility and to avoid unnecessary restriction on names.

While streams are often presented as upstream versions in
most of the examples, they're strings and are, in reality, an
extension to the name.  Your stream might be just "6" or "8" but
it could also be "experimental-build" or "performance-patches".
Current tooling shortcomings shouldn't influence how details
like this are designed.  The tooling can be fixed (or enhanced,
if you prefer).

The ordering of the fields is based on the importance of
the field to the user and most of them are optional when
people interact with modules using their package manager.
"module", "module:stream", "module:stream:version" are all
valid inputs (we do not expect people to use context directly;
it's just serialized that distinguishes individual builds for
stream expansion).  Context is indeed similar to dist-tag,
just richer.  Given the parallel availability, your modules
aren't built just for a release of Fedora, they are built for
any valid combination of their modular dependncies, with the
Fedora release being just one of them.

Note, as Patrick's already said, these names do not leak
anywhere.  Modules are not RPMs and are not handled as such.
This, AFAIK, only affects what you see in some parts of the
build and update system (and on the bus).

Also note that generally if you have access to modules, you
have access to their (structured) metadata.

P


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Fedora-Atomic 27-20180319.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