from:"Vít Ondruch"

Re: MDAPI Rewrite - Out Now in Production

2023-02-15 Thread Vít Ondruch

Exciting! Thx for the hard work.

BTW it would make sense to deprecate the Pagure repo now and here is the
ticket:

https://pagure.io/mdapi/issue/126

Vít

Dne 15. 02. 23 v 7:24 Akashdeep Dhar napsal(a):

Hello everyone,

I hope you are doing well.

I wanted to let you know that the rewritten MDAPI is out now in
production.

You can find the production deployment here[1].

The announcement of the testing deployment made on the staging
environment was made previously[2][3].

Please reach out to the project repository[4] for more information,
filing issue tickets and contributing.

Index

1. https://mdapi.fedoraproject.org/
2.
https://lists.fedoraproject.org/archives/list/de...@lists.fedoraproject.org/message/KAZOUBVPGV62UKESGNKOTWW554QDEX4Q/
3.
https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org/message/KAZOUBVPGV62UKESGNKOTWW554QDEX4Q/
4. https://github.com/fedora-infra/mdapi

Regards,
Akashdeep Dhar (he/him),
Objective Representative, Fedora Council
Red Hat Community Platform Engineering
t0xic0...@fedoraproject.org
akashd...@redhat.com

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

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

Re: FMN / notifications status

2022-11-07 Thread Vít Ondruch



Dne 05. 11. 22 v 23:22 Kevin Fenzi napsal(a):

On Wed, Nov 02, 2022 at 06:48:31PM +0100, Vít Ondruch wrote:

Dne 02. 11. 22 v 16:10 Michal Konecny napsal(a):

I looked into it and found out that this is not possible, but I was able
to make it run 5 times faster. So it should start catching up soon :-)


This sounds as much better solution. Thx a bunch!

It managed to fully catch up last night and keep in sync.
:)



Sweet. I can confirm that it seems that I have received past few 
notification instantaneously. Thx a lot.



Vít



After freeze I will be taking down fas2 and removing the openshift 3
cluster. (finally)

kevin

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


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

Re: FMN / notifications status

2022-11-02 Thread Vít Ondruch



Dne 02. 11. 22 v 16:10 Michal Konecny napsal(a):
I looked into it and found out that this is not possible, but I was 
able to make it run 5 times faster. So it should start catching up 
soon :-)



This sounds as much better solution. Thx a bunch!


Vít




Michal

On 01. 11. 22 10:11, Michal Konecny wrote:
The messages are stored in a queue, but I'm not sure if we can work 
with it as LIFO (last in first out) queue. But it's definitely an 
interesting idea.


Michal

On 01. 11. 22 9:07, Vít Ondruch wrote:


Dne 31. 10. 22 v 22:02 Kevin Fenzi napsal(a):

On Mon, Oct 31, 2022 at 06:43:08PM +0100, Vít Ondruch wrote:

Dne 19. 10. 22 v 14:45 Michal Konecny napsal(a):
1) I noticed that the queue is still growing, so I added 3 more 
workers.

Hopefully this will be enough to catch up.


Not really :( I am receiving 9 days old notifications now.

Yeah, we know. ;(

We have been trying to speed it up over the last week.

We bumped up the cpus/memory the vm has.
We started 24 worker threads instead of 6
Just a bit ago today we moved the workers to talking to redis via unix
sockets instead of tcp connections. We are hoping for about a ~20%
increase due to that.

It's currently right about 9 days delayed.

We will keep working on making it faster so it can catch up.



Thx for update and for all the effort.

I was just thinking if it was not possible to give a priority to the 
recent messages and process the old messages later when resources 
permits.



Vít




kevin

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


___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to 
infrastructure-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/

List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue



___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to 
infrastructure-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/

List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue


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

Re: FMN / notifications status

2022-11-01 Thread Vít Ondruch



Dne 31. 10. 22 v 22:02 Kevin Fenzi napsal(a):

On Mon, Oct 31, 2022 at 06:43:08PM +0100, Vít Ondruch wrote:

Dne 19. 10. 22 v 14:45 Michal Konecny napsal(a):

1) I noticed that the queue is still growing, so I added 3 more workers.
Hopefully this will be enough to catch up.


Not really :( I am receiving 9 days old notifications now.

Yeah, we know. ;(

We have been trying to speed it up over the last week.

We bumped up the cpus/memory the vm has.
We started 24 worker threads instead of 6
Just a bit ago today we moved the workers to talking to redis via unix
sockets instead of tcp connections. We are hoping for about a ~20%
increase due to that.

It's currently right about 9 days delayed.

We will keep working on making it faster so it can catch up.



Thx for update and for all the effort.

I was just thinking if it was not possible to give a priority to the 
recent messages and process the old messages later when resources permits.



Vít




kevin

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


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

Re: FMN / notifications status

2022-10-31 Thread Vít Ondruch



Dne 19. 10. 22 v 14:45 Michal Konecny napsal(a):
1) I noticed that the queue is still growing, so I added 3 more 
workers. Hopefully this will be enough to catch up.



Not really :( I am receiving 9 days old notifications now.


Vít




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

Re: FMN / notifications status

2022-10-19 Thread Vít Ondruch


First of all, thanks everybody to work on this.

However, I have two questions:

1) Will it ever catch up?

2) Could the Date of the email correspond with the event timestamp?


Vít


Dne 17. 10. 22 v 10:22 Michal Konecny napsal(a):
Just a note, the old FMN code is living in 
https://github.com/fedora-infra/fmn in develop branch, which is not 
default. The default one is fmn-next, which is the complete rewrite. 
So if you want to help working on current FMN, you need to start from 
develop branch.


Michal

On 14. 10. 22 18:32, Kevin Fenzi wrote:

current status: We have the backend processing it's queue.
The only tracebacks left are due to changes in format of
fedora-messaging messages vs what it's fedmsg-meta says, which were
present before on the python2 version as well. :)

It's taking about 4seconds per message to find recipients, which isn't
great, but hopefully will allow it to catch up. We can also look at
adding some more workers (it has 6 right now).

It seems to be processing/sending messages from 3 days ago right now.
I think older messages are still in the queue, but got requeued at the
back, so might not show up until it catches up.

We still need to fix the frontend's bad redirect. Anyone who wants to
help with that, help welcome. ;)

I can confirm it's no longer making any fas calls at all. Hurray!

So, upcoming:

* Fix web redirect so people can get to the interface again.
* Merge all the changes Michal and I made back to the codebase. There
were a lot of changes!
* There's some minor changes we could make, like replacing 'freenode'
everywhere with 'librea.chat'. If anyone would like to submit PR's they
would be welcome.
* See if it's catching up or if we need more workers.
* After f37 is out the door, I will be finally taking down fas2 and the
openshift3.11 clusters. Hurray!
* Eventually, the new FMN will land and replace this thing.

Thanks for everyone's patience while we worked on this.

kevin

___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to 
infrastructure-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/

List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to 
infrastructure-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/

List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue


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

Re: The state of mailing lists/mailman (not great)

2022-09-07 Thread Vít Ondruch



Dne 06. 09. 22 v 15:45 Stephen Smoogen napsal(a):



On Fri, 2 Sept 2022 at 16:10, Stephen Smoogen  wrote:


This is a general 'what I am seeing in the infrastructure' email
taking various comments I made in irc into a more formal email



Looking at the last month of mailing lists which archived mails, we 
have about 120 email out of 700+ email lists which got at least one 
email. The 40 most active emails in August to beginning of September were


  36148 scm-commits
   2178 package-announce
   1737 go-sig
   1729 package-review
   1163 rust-sig
   1145 python-sig
    864 devel
    786 releng-cron
    676 gnome-sig
    449 epel-package-announce
    441 perl-devel
    419 neuro-sig
    344 users
    318 epel-packagers-sig
    317 infra-sig
    313 kde-sig
    313 arch-excludes
    289 container-sig
    229 test-reports
    192 deepinde-sig
    186 ruby-packagers-sig



Uh, this ^^ took me by surprise. I don't even know there would be any 
incoming traffic. This ML was created, probably because we needed when 
we established the associated group. I am quite sure that I am notified 
about the activity on related components by different means (FMN) then 
this ML.



Vít



    156 virt-maint
    151 kernel
    141 fedoramagazine-tips
    126 freeipa-users
    124 perl-maint
    108 epel-devel
    104 rpm-software-management
    102 openstack-sig
    101 meetingminutes
     98 test
     97 i18n-bugs
     97 certbot-sig
     86 kexec
     75 java-sig-commits
     67 dns-sig
     50 nodejs-sig
     45 lvm2-commits
     45 infrastructure
     44 389-users

I am wondering if some of these lists would be better using something 
like public inbox https://lwn.net/Articles/748184/ like sourceware is 
using https://inbox.sourceware.org/. Various announcement lists and 
things like scm-commits do not need to have interactive webpages like 
mailman3 hyperkitty give since they are limited to few people.

--
Stephen Smoogen, Red Hat Automotive
Let us be kind to one another, for most of us are fighting a hard 
battle. -- Ian MacClaren


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


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

Re: openshift 3->4 moves status and info needed

2022-06-22 Thread Vít Ondruch



Dne 17. 06. 22 v 16:07 Pierre-Yves Chibon napsal(a):

On Fri, Jun 17, 2022 at 12:25:08PM +0200, Vít Ondruch wrote:

Dne 15. 06. 22 v 1:49 Kevin Fenzi napsal(a):

Greetings everyone.

I finally had a quiet afternoon to really dig into the ocp3->4
migration.

We have a total of 64 unique applications/projects over the 4 clusters
(ocp3 prod/stg and ocp4 prod/stg).

Of those 20 have been moved to ocp4 (either stg or prod or both).

There's 4 that are sort of in the midst of moving to ocp4 prod, but need
some more tweaking (flatpak-indexer, release-monitoring,
discourse2fedmsg, transtats).

I'd like to propose removing the following 9 entirely:
REMOVE: simple-koji-ci.yml
( This was retired a long time ago)


Does it mean that simple-koji-ci will be decommissioned soon? That is sad
news.

It has not been running for quite a while now.
There is an equivalent service provided by the fedora-ci folks, so you shouldn't
have seen it in any PR for a long time.



Ah, so the "Fedora CI - scratch build" is something different. Good :) 
Thx for clarification.



Vít





Pierre

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


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

Re: openshift 3->4 moves status and info needed

2022-06-17 Thread Vít Ondruch



Dne 15. 06. 22 v 1:49 Kevin Fenzi napsal(a):

Greetings everyone.

I finally had a quiet afternoon to really dig into the ocp3->4
migration.

We have a total of 64 unique applications/projects over the 4 clusters
(ocp3 prod/stg and ocp4 prod/stg).

Of those 20 have been moved to ocp4 (either stg or prod or both).

There's 4 that are sort of in the midst of moving to ocp4 prod, but need
some more tweaking (flatpak-indexer, release-monitoring,
discourse2fedmsg, transtats).

I'd like to propose removing the following 9 entirely:
  
REMOVE: simple-koji-ci.yml

   ( This was retired a long time ago)



Does it mean that simple-koji-ci will be decommissioned soon? That is 
sad news.


Vít




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

Re: About JS framework

2022-05-11 Thread Vít Ondruch


Hm, is this some favorite SPAM thread?


Vít


Dne 11. 05. 22 v 13:19 Alex Maddyson napsal(a):

Hi,
I can recommend you to read this great article about engineers, I think that it 
will be interesting for those who are in this industry.
https://engre.co/blogs/articles/what-is-a-propulsion-engineer/
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure


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

Re: status.fp.org concept

2021-05-03 Thread Vít Ondruch

I like it. Nevertheless, I'll be missing the current page, which lists 
the various services Fedora provides.



Vít


Dne 30. 04. 21 v 14:23 Ryan Lerch napsal(a):

Hi all,

I have been working on this ticket for an updated version of 
status.fedoraproject.org .


https://pagure.io/fedora-infrastructure/issue/9858 



I have come up with a proof of concept that fills all the requirements 
specified in the the ticket, and looking for feedback / thoughts on 
this new approach.


The source of the POC is here:

https://github.com/ryanlerch/status-playground/ 



and a recent build version of what it looks like is here:

https://ryanlerch.github.io/status-playground/ 



cheers,
ryanlerch



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

Re: Anitya (release-monitoring.org) 1.0.0 available

2021-02-01 Thread Vít Ondruch

Please see the attached JSON.

Thx

Vít

Dne 28. 01. 21 v 10:39 Michal Konecny napsal(a):

Hi Vit,

I didn't change anything regarding the FMN that should create this
behavior. So I'm not sure from where is this coming.

I can only think that this could be somewhat related to the new
`anitya.project.version.update.v2` topic, but I'm not sure why it's
affecting the FMN notifications.

Could you share your notifications settings?

Michal

On 27. 01. 21 12:40, Vít Ondruch wrote:
Recently, I have started to receive notifications such as the one in
attachment and I wonder what is their purpose? They don't provide any
meaningful information starting by the "fedmsg notification" subject.

Vít

Dne 22. 01. 21 v 10:56 Michal Konecny napsal(a):

Hi everyone,

today I deployed a new version of Anitya on production [0]. I
decided that Anitya is mature enough to have version 1.0.0. So here
it is.

And what this versions brings? Plenty of changes, here is the list
of the most interesting ones:

* Add preview mode
Now you can try your changes before submitting them, on the edit and
add project page is a new button "Test check" which will take the
fields from the form and do a check for releases above them. Nothing
is changed in the database during test check.

* Flag pre-release versions
Yes, you are reading it right. Anitya is now flagging versions that
are considered unstable, it uses the version scheme recognition and
above that you can add your own filter when editing project.

* Message schema 2.0.0
The Anitya message schema now contains a new topic
"anitya.project.version.update.v2". This topic will send message
that has "upstream_versions" field which contains all the newly
found versions, not only the latest one. And it also contains a
"stable_versions" field, so you can look if some of the newly
versions is stable or not. With this version
"anitya.project.version.update" is now deprecated!

* Add version filter for project
Anitya now allows user to add their own version filter, if you see
any bogus version, you can just edit project and add the string to
filter (This will not delete any version that was already retrieved,
but you can flag a project and ask admin to do it for you and it
will never be retrieved again).

* Project archiving
Anitya 1.0.0 allows admins to archive projects if it seems
reasonable (project dead upstream) for the sake of history. Archived
projects can't be edited and are not checked for new versions, but
still could be found in Anitya.

* Projects menu is rewritten
The projects menu now contains items that are more sensible to
current state of Anitya, you can see projects that were successfully
updated (sorted by the time of update from newest), failed to update
(sorted by the number of failed attempts from highest number), never
updated (incorrectly set up projects, where update was never
successful, sorted by the date of creation from oldest) and archived
projects.

* Updated documentation
The documentation was fully rewritten to reflect the current state
of Anitya. User guide was added containing use cases that could be
done by user. User admin guide was added for users in Anitya with
Admin rights. And the Admin guide and Contribution guide was
verified that these steps are working with current version of Anitya.

If you want to see whole list of changes, see Anitya 1.0.0 release
on GitHub [1].

I hope this release will bring joy to your life and solve at least
some of the pain points people had with Anitya.

Michal
Mage from release-monitoring.org

P.S.: If you want to try something in Anitya without the fear of
breaking anything, you can try it on staging instance [2].

[0] - https://release-monitoring.org/
[1] - https://github.com/fedora-infra/anitya/releases/tag/1.0.0
[2] - https://stg.release-monitoring.org/
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to
infrastructure-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/

List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org

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

Anytia.json
Description: application/json

OpenPGP_signature
Description: OpenPGP digital signature
___
infrastru

Re: Anitya (release-monitoring.org) 1.0.0 available

2021-01-27 Thread Vít Ondruch

Recently, I have started to receive notifications such as the one in
attachment and I wonder what is their purpose? They don't provide any
meaningful information starting by the "fedmsg notification" subject.

Vít

Dne 22. 01. 21 v 10:56 Michal Konecny napsal(a):

Hi everyone,

today I deployed a new version of Anitya on production [0]. I decided
that Anitya is mature enough to have version 1.0.0. So here it is.

And what this versions brings? Plenty of changes, here is the list of
the most interesting ones:

* Message schema 2.0.0
The Anitya message schema now contains a new topic
"anitya.project.version.update.v2". This topic will send message that
has "upstream_versions" field which contains all the newly found
versions, not only the latest one. And it also contains a
"stable_versions" field, so you can look if some of the newly versions
is stable or not. With this version "anitya.project.version.update" is
now deprecated!

* Add version filter for project
Anitya now allows user to add their own version filter, if you see any
bogus version, you can just edit project and add the string to filter
(This will not delete any version that was already retrieved, but you
can flag a project and ask admin to do it for you and it will never be
retrieved again).

* Project archiving
Anitya 1.0.0 allows admins to archive projects if it seems reasonable
(project dead upstream) for the sake of history. Archived projects
can't be edited and are not checked for new versions, but still could
be found in Anitya.

* Projects menu is rewritten
The projects menu now contains items that are more sensible to current
state of Anitya, you can see projects that were successfully updated
(sorted by the time of update from newest), failed to update (sorted
by the number of failed attempts from highest number), never updated
(incorrectly set up projects, where update was never successful,
sorted by the date of creation from oldest) and archived projects.

* Updated documentation
The documentation was fully rewritten to reflect the current state of
Anitya. User guide was added containing use cases that could be done
by user. User admin guide was added for users in Anitya with Admin
rights. And the Admin guide and Contribution guide was verified that
these steps are working with current version of Anitya.

If you want to see whole list of changes, see Anitya 1.0.0 release on
GitHub [1].

I hope this release will bring joy to your life and solve at least
some of the pain points people had with Anitya.

Michal
Mage from release-monitoring.org

P.S.: If you want to try something in Anitya without the fear of
breaking anything, you can try it on staging instance [2].

List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org
--- Begin Message ---
Notification time stamped 2021-01-23 00:21:53 UTC

https://release-monitoring.org/project/4673/

--
You received this message due to your preference settings at
https://apps.fedoraproject.org/notifications/vondruch.id.fedoraproject.org/email/50917--- End Message ---

Re: Possible outdated Jenkins jobs

2020-11-03 Thread Vít Ondruch

I have rather suggesting the opposite direction, i.e. dropping it and if 
I by a chance found the energy, I'll set it up again. But thx for 
cheering me up ;)



Vít


Dne 03. 11. 20 v 18:30 Leonardo Rossetti napsal(a):

ha no worries we can keep it and make it work :)

On Mon, Nov 2, 2020 at 2:16 PM Vít Ondruch <mailto:vondr...@redhat.com>> wrote:



Dne 02. 11. 20 v 15:30 Leonardo Rossetti napsal(a):
>
https://jenkins-fedora-infra.apps.ci.centos.org/job/ruby-chkbuild/
<https://jenkins-fedora-infra.apps.ci.centos.org/job/ruby-chkbuild/>
>
<https://jenkins-fedora-infra.apps.ci.centos.org/job/ruby-chkbuild/
<https://jenkins-fedora-infra.apps.ci.centos.org/job/ruby-chkbuild/>>
>
> https://jenkins-fedora-infra.apps.ci.centos.org/job/ruby/
<https://jenkins-fedora-infra.apps.ci.centos.org/job/ruby/>
> <https://jenkins-fedora-infra.apps.ci.centos.org/job/ruby/
<https://jenkins-fedora-infra.apps.ci.centos.org/job/ruby/>>


I have never found the energy to make this work after migration from
Fedora CI to CentOS CI :/


Vít
___
infrastructure mailing list --
infrastructure@lists.fedoraproject.org
<mailto:infrastructure@lists.fedoraproject.org>
To unsubscribe send an email to
infrastructure-le...@lists.fedoraproject.org
<mailto:infrastructure-le...@lists.fedoraproject.org>
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
<https://docs.fedoraproject.org/en-US/project/code-of-conduct/>
List Guidelines:
https://fedoraproject.org/wiki/Mailing_list_guidelines
<https://fedoraproject.org/wiki/Mailing_list_guidelines>
List Archives:

https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org

<https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org>



--

Leonardo Rossetti

Senior Software Engineer,

Red Hat <https://www.redhat.com>

lross...@redhat.com <mailto:lross...@redhat.com>
M: +55-11-99703-0621 

<https://www.redhat.com>


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

Re: The approach to extract all Fedora srpm?

2020-09-01 Thread Vít Ondruch


Dne 31. 08. 20 v 22:50 clime napsal(a):
> On Mon, 31 Aug 2020 at 22:28, Jean-Baptiste Holcroft
>  wrote:
>> Hello,
>>
>> I would like to provide translation memories for translators and measure 
>> localization progress over Fedora versions (Linux wide).
>> I need to get upstream's content to get translation files such as po/gettext 
>> files.
>> To do that, I need to learn how to interact with Fedora packages to reach 
>> the SRPM.
>>
>> The easiest way would probably be to run `dnf list --all` in a virtual 
>> machine or container for each Fedora release.
>> An alternative could be to use datagrepper using 
>> org.fedoraproject.prod.buildsys.build.state.change? Using this method would 
>> allow me to catch new changes, but how do I load previous events or do the 
>> first initialization?
>> Is there other ways to get all the SRPM of a Fedora release?
> As an alternative approach, you could download
> https://src.fedoraproject.org/git-seed-latest.tar.xz


You have meant https://src.fedoraproject.org/repo/git-seed-latest.tar.xz
I guess.


Vít


>  and keep the git
> history fresh locally (won't catch the newly added packages though).
> then pull the needed data from the spec files.
>
> clime
>
>> thanks a lot for your help,
>>
>> I had a discussion on fedora-i18n [0], and Ben Cotton suggested me to ask my 
>> question here.
>> I tried to document what I want to do in this wiki page page [1]
>>
>> [0] 
>> https://lists.fedoraproject.org/archives/list/i...@lists.fedoraproject.org/thread/XYQQPX2XOIEGTX4QEF3I4CA6TFPYP3PC/
>> [1] https://fedoraproject.org/wiki/User:Jibecfed/LinuxLocalizationMeasurement
>> ___
>> infrastructure mailing list -- infrastructure@lists.fedoraproject.org
>> To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
>> Fedora Code of Conduct: 
>> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>> List Archives: 
>> https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org
> ___
> infrastructure mailing list -- infrastructure@lists.fedoraproject.org
> To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org

Re: Is the -ow...@fedoraproject.org alias documented somewhere?

2020-06-22 Thread Vít Ondruch


Dne 20. 06. 20 v 19:34 Kevin Fenzi napsal(a):
> On Fri, Jun 19, 2020 at 11:07:59AM +0200, Vít Ondruch wrote:
>> Dne 18. 06. 20 v 19:48 Kevin Fenzi napsal(a):
>>> On Thu, Jun 18, 2020 at 10:12:11AM +0200, Vít Ondruch wrote:
>>>> Dne 17. 06. 20 v 19:54 Kevin Fenzi napsal(a):
>>>>> On Tue, Jun 16, 2020 at 09:23:38AM +0200, Vít Ondruch wrote:
>>>>>
>>>>> Theres not a seperate one for epel, but it might be possible to make
>>>>> one looking at bugzilla overrides.
>>>> Just to give you a bit of context, this alias would be useful when
>>>> introducing new package into RHEL, where the package is already present
>>>> in EPEL and therefore have to be removed. So it would help with a way to
>>>> contact the relevant people without the need of gathering their emails.
>>> Yeah, +1. This would be a great use for that alias. 
>>
>> Should I open a ticket? Is this realistic any time soon?
> For documenting the aliases? Well, you can edit the wiki... or did you
> want a better place for it, like in docs?
>
> Or did you mean getting RHEL maintainers to mail it when introducing new
> packages to RHEL? Thats beyond our scope here, and would have to be some
> internal process. 
>

Sorry for getting lost you here. I was still talking about the EPEL
email alias. So is the EPEL email alias thing which could be implemented
soon so is it worth of opening ticket?


Vít




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

Re: Is the -ow...@fedoraproject.org alias documented somewhere?

2020-06-19 Thread Vít Ondruch


Dne 18. 06. 20 v 19:48 Kevin Fenzi napsal(a):
> On Thu, Jun 18, 2020 at 10:12:11AM +0200, Vít Ondruch wrote:
>> Dne 17. 06. 20 v 19:54 Kevin Fenzi napsal(a):
>>> On Tue, Jun 16, 2020 at 09:23:38AM +0200, Vít Ondruch wrote:
>>>
>>> Theres not a seperate one for epel, but it might be possible to make
>>> one looking at bugzilla overrides.
>>
>> Just to give you a bit of context, this alias would be useful when
>> introducing new package into RHEL, where the package is already present
>> in EPEL and therefore have to be removed. So it would help with a way to
>> contact the relevant people without the need of gathering their emails.
> Yeah, +1. This would be a great use for that alias. 


Should I open a ticket? Is this realistic any time soon?


Vít





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

Re: Is the -ow...@fedoraproject.org alias documented somewhere?

2020-06-18 Thread Vít Ondruch


Dne 17. 06. 20 v 19:54 Kevin Fenzi napsal(a):
> On Tue, Jun 16, 2020 at 09:23:38AM +0200, Vít Ondruch wrote:
>> Hi,
>>
>> I just wonder if the `-ow...@fedoraproject.org` email alias is
>> documented somewhere. And are there other email aliases? E.g. can I
>> reach the EPEL maintainer of a package? Maybe this page [1] could be
>> used to document this.
> Yeah, I don't know of anywhere it is. 
>
> That said, '-owner' is the old version and we should probibly
> retire it soon. The new/preferred one is '-maintainers' 


Never heard about -maintainers. So do I understand correctly that this
alias is already in place?


>
> Theres not a seperate one for epel, but it might be possible to make
> one looking at bugzilla overrides.


Just to give you a bit of context, this alias would be useful when
introducing new package into RHEL, where the package is already present
in EPEL and therefore have to be removed. So it would help with a way to
contact the relevant people without the need of gathering their emails.


Vít




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

Is the -ow...@fedoraproject.org alias documented somewhere?

2020-06-16 Thread Vít Ondruch

Hi,

I just wonder if the `-ow...@fedoraproject.org` email alias is
documented somewhere. And are there other email aliases? E.g. can I
reach the EPEL maintainer of a package? Maybe this page [1] could be
used to document this.


VĂt




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

Re: Proposing keeping multiple versions of the same package in the updates repo

2020-03-24 Thread Vít Ondruch


Dne 24. 03. 20 v 16:30 Adam Williamson napsal(a):
> On Tue, 2020-03-24 at 10:03 +0100, Vít Ondruch wrote:
>> +1
>>
>> I would love this for Rawhide. This would also allow `dnf downgrade` to
>> work, which would be very useful when things go south. In stable
>> releases, you could in theory downgrade from version in `updates`
>> repository to version from `fedora` repository`, but that is not
>> possible in Rawhide :/
> It's pretty easy to do this with the Koji CLI:
>
> koji download-build --arch=x86_64 --arch=noarch (NVR)
> dnf downgrade *.rpm


While this might sound useful, it is not that useful when your system is
borked and you want to get it up and running again.

IOW this is strawman to the original request and my reasoning for the +1.


Vít


> usually will do the trick (adjust for arch, obviously). For stable
> releases, all packages that were ever made stable updates are kept
> around, AIUI - they are exempt from garbage collection. For Rawhide I
> think things get garbage collected after a while, but they're usually
> there for several weeks first.
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org

Re: Proposing keeping multiple versions of the same package in the updates repo

2020-03-24 Thread Vít Ondruch

+1

I would love this for Rawhide. This would also allow `dnf downgrade` to
work, which would be very useful when things go south. In stable
releases, you could in theory downgrade from version in `updates`
repository to version from `fedora` repository`, but that is not
possible in Rawhide :/


Vít


Dne 24. 03. 20 v 1:12 Michel Alexandre Salim napsal(a):
> Hi,
>
> We run a diverse fleet of Linux laptops and desktops (at Facebook), and 
> sometimes there are regressions that affect some of our fleet but not others.
>
> To pick the latest example:
> - pulseaudio 1.3.99.1 (both -1 and -2) breaks Bluetooth support on a Dell XPS 
> 15: https://bugzilla.redhat.com/show_bug.cgi?id=1814556
> - but it fixes HDA audio input on ThinkPad T490s and X1 Carbon: 
> https://bodhi.fedoraproject.org/updates/FEDORA-2020-c3e19f5098
>
> We've had similar issues with kernel regressions (e.g. 5.4 kernels had issues 
> with Intel GPUs, and on ThinkPads with Nvidia GPUs).
>
> (Ideally we catch all this before they land -- over the medium term I'm 
> trying to find a way to encourage our users to help test updates)
>
> Would it be possible to keep 2 or 3 versions of the same package in the 
> updates repo, so we can easily keep some of our fleet at a previous version 
> known to work on that particular hardware? And is there a process for 
> proposing this (e.g. file a ticket on Pagure)?
>
> Our workaround right now is to check in the older versions in our internal 
> repo.
>
> Thanks,
>
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org

Re: CPE Weekly: 2019-10-18

2019-10-21 Thread Vít Ondruch


Dne 18. 10. 19 v 20:13 Tomasz Torcz napsal(a):
> On Fri, Oct 18, 2019 at 05:54:05PM +0100, Aoife Moloney wrote:
>>
>>-
>>
>>Bodhi 5.0 beta has been deployed in staging this week
>>-
>>
>>   Looksto be on track for ’dev-complete’
>>   -
>>
>>Koji Project
>>-
>>
>>   Db-koji01 performance problems: Gathering query logs and asking for
>>   help from koji developers
>>   https://pagure.io/fedora-infrastructure/issue/8292
>>   -
>>
>>   Overview page of the remaining blockers and dependencies organized at:
>>   -
>>
>>  https://hackmd.io/Gbuu9JOPR--Y2yNCBEYI5A?view
>>  -
>>
>> Input welcome for anything that would be missing
>> -
>>
>>  https://github.com/fedora-infra/bodhi/projects/3
>>  -
>>
>> High priority items in the “Ready” column are all
>> hard-dependency for pushing multi-builds to production
>> -
>  
>  
>> If you have any comments or any feedback on this information blast, send
>> them my way :)
>
>   Thanks for the report.  One question: what's with the strange
> formatting?  Multi-lvel indentation and dashes in empty lines?
>
>

It is probably some weird conversion into plain text. HTML version looks OK.


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

Re: Release monitoring: no scratch builds with non URL source files in repo

2019-05-30 Thread Vít Ondruch


Dne 30. 05. 19 v 11:17 Ankur Sinha napsal(a):
> Hello,
>
> I've recently seen this on an upstream release monitoring bug:
>
> "The following Sources of the specfile are not valid URLs so we cannot
> automatically build the new version for you.  Please use URLs in your
> Source declarations if possible."


I guess rpmlint would complain as well. May be you could use a URL to
the file in dist-git repo?

https://src.fedoraproject.org/rpms/urlscan/raw/master/f/muttrc

Not sure if that is not too daring, but it is "upstream" url of that
file, isn't it?


Vít


>
> https://bugzilla.redhat.com/show_bug.cgi?id=1612483#c10
>
> The concerned file here is an extra doc file that is included in the
> repo. Is it possible to handle this case somehow? (Was this always the
> case?)
>
> https://src.fedoraproject.org/rpms/urlscan/tree/master
>
>
> ___
> infrastructure mailing list -- infrastructure@lists.fedoraproject.org
> To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org


signature.asc
Description: OpenPGP digital signature
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org

Re: Deprecating Autocloud

2019-04-29 Thread Vít Ondruch


Dne 29. 04. 19 v 14:20 Pierre-Yves Chibon napsal(a):
> On Mon, Apr 29, 2019 at 08:10:59AM -0400, Neal Gompa wrote:
>> On Mon, Apr 29, 2019 at 7:51 AM Stephen John Smoogen  
>> wrote:
>>>
>>>
>>> On Mon, 29 Apr 2019 at 07:35, Neal Gompa  wrote:
 On Mon, Apr 29, 2019 at 7:21 AM Kamil Páral  
 wrote:
>> On Wed, Apr 24, 2019 at 12:19 AM Kevin Fenzi > wrote:
>>
>>
>> It will be nice but I am not aware of any other system in place which 
>> would
>> replace checks performed by autocloud.
>>
>> (CC'ed tflink and kparal)
>> Does taskotron provides capability to perform tests on Fedora cloud 
>> Images
>> like booting images and other basic checks?
> (My email to the list was rejected because I'm not subscribed, let me try 
> again from the web UI...)
>
> Theoretically it is possible using nested virt. However, Taskotron is 
> going away as well. The replacement is Fedora CI:
> https://docs.fedoraproject.org/en-US/ci/
>
 But Fedora CI is broken and/or vaporware. How can we replace Taskotron
 with that?

>>> Honestly.. weren't we saying the same damn thing about taskotron until 
>>> Fedora CI became the latest thing to rail about. It was constantly 'why do 
>>> you spend time on this broken crap' and then it becomes the 'oh why are you 
>>> replacing my favorite thing in the world'. I am pretty sure there are 
>>> multiple thesis and doctorates on the codependency that OpenSource 
>>> developers exhibit..
>>>
>>>
>> I actually don't remember this for Taskotron... I'm pretty sure that's
>> because most of us can't interact with it.
>>
>> The problem with Fedora CI is that it's documentation is useless and
>> attempts to use the system end in miserable failure.
> Sorry for asking, but could you point me to the tickets you've opened for the
> issues you've seen/faced?


This is my experience with CI if you wish:


https://pagure.io/standard-test-roles/issue/182

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

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


Unresolved tickets opened for a year.


Vít

___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org

Re: Future of fedora-packages

2019-02-27 Thread Vít Ondruch


Dne 26. 02. 19 v 23:42 Ryan Lerch napsal(a):
>
>
> On Wed, 27 Feb 2019 at 05:39, Clement Verna  > wrote:
>
> Hi all,
>
> fedora-packages [0] code base is showing its age. The code base and
> the technology stack  (Turbogears2 [1] web framework and the Moksha
> [2] middleware) is currently not ready for Python3 and I am not
> planning to do the work required to make it Python3 compatible, so the
> application will stop working when Fedora 29 is EOL.
>
> In order to keep the service running, I have started a Proof Of
> Concept (fedora-search [3]) to replace the backend of the application.
>

Backend of fedora-packages is mdapi, isn't it? What would be the difference?


> Fedora-search would be a REST API service offering full test search
> API. Such a service would then be available for other application to
> use, fedora-packages would then become a frontend only application
> using the service provided by fedora-search.
>
> While the POC shows that this is a viable solution, I don't think that
> we should be proceeding that way, for the simple reason that this add
> yet another code base to maintain, I think we should use this
> opportunity to consider using Elasticsearch instead of maintaining our
> own "search engine".
>
> I think that Elasticsearch offers quite a few advantages :
>   - Powerful Query language
>   - Python bindings
>   - Javascript bindings
>   - Can be deployed in our infrastructure or used as a service
>   - Can be useful for other applications ( docs.fp.o, pagure, ??)
>
> So what is the general feeling about using Elasticsearch in our
> infrastructure ? Should we look at deploying a cluster in our infra /
> Should we approach the Council to see if we can get founding to have
> this service hosted by Elastic ?
>
> Thanks
> Clément
>
>
> From an information point of view, the package-centric view of
> Fedora-packages is quite similar to the pagure dist-git. Would it
> worth investgating merging the front-end functionality of packages
> (lists of builds, bugs, updates, etc) into pagure dist-git, and
> retiring the Fedora packages front end?


+1


V.


>
> —ry
>
>
>
> [0] - https://apps.fedoraproject.org/packages/
> [1] - http://www.turbogears.org/
> [2] - https://mokshaproject.github.io/mokshaproject.net/
> [3] - https://github.com/fedora-infra/fedora-search
> ___
> infrastructure mailing list --
> infrastructure@lists.fedoraproject.org
> 
> To unsubscribe send an email to
> infrastructure-le...@lists.fedoraproject.org
> 
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines:
> https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> 
> https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org
>
>
> ___
> infrastructure mailing list -- infrastructure@lists.fedoraproject.org
> To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org

Re: Koji / epel-7 - What's going on?

2018-11-21 Thread Vít Ondruch


Dne 20. 11. 18 v 23:52 Kevin Fenzi napsal(a):
> On 11/20/18 2:39 PM, Frantisek Zatloukal wrote:
>> Hi,
>> I am currently trying to build new resultsdb[0] into epel7-candidate.
>> However, I am facing some (weird?) behavior around python-flask,
>>
>> I am able to do a successful build of resultsdb (depending on python-flask)
>> in mock epel-7 and koji scratch epel-7 [1]. However, it is failing on
>> not-available python-flask in koji to epel-7-candidate [2].
>>
>> Am I overlooking something?
>>
>> Thanks very much!
>>
>> [0] https://src.fedoraproject.org/rpms/resultsdb/blob/epel7/f/resultsdb.spec
>> [1] https://koji.fedoraproject.org/koji/taskinfo?taskID=31025152
>> [2] https://koji.fedoraproject.org/koji/taskinfo?taskID=31025187
> flask was pulled into rhel-extras (for docker distribution I think) and
> when it was, it was only published for x86_64.
>
> Your package is noarch, but flask is not.
>
> So, you happened to get a x86_64 builder with your scratch build, but
> your real build got a ppc builder where flask is not available. ;(
>
> I think you should be able to pass "Exclusivearch: noarch x86_64" 


Was this resolved?

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


V.


> and
> have it work. If not, you can just resubmit your build until you get a
> x86_64 builder.
>
> kevin
>
>
> ___
> infrastructure mailing list -- infrastructure@lists.fedoraproject.org
> To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org


signature.asc
Description: OpenPGP digital signature
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org

Re: Slow Pagure.io

2018-05-09 Thread Vít Ondruch



Dne 7.5.2018 v 21:17 Todd Zullinger napsal(a):
> Anatoli Babenia wrote:
>> It is the same with pagure itself -
>> https://pagure.io/pagure/issue/3207
>>
>> DB is missing indexes? Or there is some loop in Pagure
>> that goes slow because of number of issues? How to profile
>> it?
> It was something like that.  With many thanks to Patrick,
> this issue should be largely fixed now.  What took close to
> 10 minutes to load (if you were patient enough to let it go
> that long) now takes closer to 5 seconds.
>
> If that's not the case for anyone who was experiencing this,
> please reply.
>
> Thanks again to Patrick for digging into this.

First load of [1] took like 15s for me, but the second try took
approximately 2,5s. The issue list of pagure [2] loaded in reasonable
time. So whatever was the fix, it looks promising.


V.

[1] https://pagure.io/releng/issues
[2] https://pagure.io/pagure/issues


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



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

Re: Slow Pagure.io

2018-05-04 Thread Vít Ondruch



Dne 4.5.2018 v 16:34 Pierre-Yves Chibon napsal(a):
> On Fri, May 04, 2018 at 04:29:20PM +0200, Vít Ondruch wrote:
>> Hi,
>>
>> Pagure.io is so slow for me to that point that I simple can't open
>> ticket to report it. IOW, I am trying to load
>> https://pagure.io/fedora-infrastructure/issues in my browser and it does
>> not work, it just waits for response :/
>
> Just basic ideas/questions:
> Do you have some plugins/extensions installed in your browser?

I have some, but I don't think I have anything special. I definitely
don't have any addblocker or so.
> Did you try in private browsing mode

Actually trying with private mode now. I got to
https://id.fedoraproject.org but the redirect back to pagure does not
work ...

>  or with a clean profile?
> If you try from another location (home, coffee shop) do you see the same
> slowness?

Working from home. But I don't remember to have such issues.

V.

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

Re: Slow Pagure.io

2018-05-04 Thread Vít Ondruch

If I go to pagure.io/login, I can get logged in, but then I can't access
the issues again ...


V.


Dne 4.5.2018 v 16:34 Vít Ondruch napsal(a):
> I removed cookies and the page can be loaded just fine, but it appears I
> can't login now ...
>
> Vít
>
>
> Dne 4.5.2018 v 16:29 Vít Ondruch napsal(a):
>> Hi,
>>
>> Pagure.io is so slow for me to that point that I simple can't open
>> ticket to report it. IOW, I am trying to load
>> https://pagure.io/fedora-infrastructure/issues in my browser and it does
>> not work, it just waits for response :/
>>
>> ~~~
>>
>> $ curl https://pagure.io/fedora-infrastructure/issues -o /dev/null
>>   % Total    % Received % Xferd  Average Speed   Time    Time Time 
>> Current
>>  Dload  Upload   Total   Spent    Left 
>> Speed
>> 100  107k  100  107k    0 0  30755  0  0:00:03  0:00:03 --:--:--
>> 30764
>>
>>
>> $ traceroute pagure.io
>> traceroute to pagure.io (152.19.134.147), 30 hops max, 60 byte packets
>>  1  _gateway (192.168.0.1)  3.274 ms  4.385 ms  4.320 ms
>>  2  * * *
>>  3  ip-86-49-1-161.net.upcbroadband.cz (86.49.1.161)  22.197 ms  22.094
>> ms  22.066 ms
>>  4  cz-brn-pop40-ra2-vla2191.net.upc.cz (84.116.220.246)  121.057 ms 
>> 124.204 ms  124.182 ms
>>  5  cz-brn-pop40-ra1-vla2110.net.upc.cz (84.116.221.41)  126.583 ms 
>> 126.456 ms  126.449 ms
>>  6  cz-prg01a-ra4-vla2109.net.upc.cz (84.116.221.37)  126.402 ms 
>> 111.096 ms  116.115 ms
>>  7  de-fra04a-rc1-ae33-0.aorta.net (84.116.135.5)  110.803 ms  137.982
>> ms  137.875 ms
>>  8  de-fra04d-rc1-ae26-0.aorta.net (84.116.138.238)  137.842 ms  137.777
>> ms  137.724 ms
>>  9  * * *
>> 10  us-nyc01b-rd2-ae9-0.aorta.net (84.116.140.170)  138.336 ms  138.298
>> ms  115.267 ms
>> 11  us-nyc01b-ri2-ae3-0.aorta.net (84.116.137.194)  114.465 ms  112.698
>> ms  110.019 ms
>> 12  nyc2-brdr-01.inet.qwest.net (63.235.40.165)  136.127 ms  136.117 ms 
>> 136.086 ms
>> 13  dca-edge-23.inet.qwest.net (67.14.6.158)  159.519 ms  159.547 ms 
>> 161.527 ms
>> 14  65.120.78.78 (65.120.78.78)  136.700 ms  135.992 ms  135.886 ms
>> 15  uncmanning-to-rtp-ip-asr-gw.ncren.net (128.109.19.90)  132.844 ms 
>> 137.504 ms  136.760 ms
>> 16  core-m-v1214.net.unc.edu (152.19.255.66)  135.283 ms  136.117 ms 
>> 138.533 ms
>> 17  152.19.255.70 (152.19.255.70)  128.737 ms  128.655 ms  128.518 ms
>> 18  152.19.255.166 (152.19.255.166)  147.476 ms  132.950 ms  137.336 ms
>> 19  vmhost1-rsa.fedora.ibiblio.org (152.19.134.147)  126.626 ms !X 
>> 130.794 ms !X  121.215 ms !X
>> ~~~
>>
>>
>> The strange thing is that the pagure title page or the project overview
>> can be loaded just fine and neither the tools above shows any suspicious
>> behavior to me.
>>
>>
>> Vít
>>
>>
>> ___
>> infrastructure mailing list -- infrastructure@lists.fedoraproject.org
>> To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
> ___
> infrastructure mailing list -- infrastructure@lists.fedoraproject.org
> To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org

Slow Pagure.io

2018-05-04 Thread Vít Ondruch

Hi,

Pagure.io is so slow for me to that point that I simple can't open
ticket to report it. IOW, I am trying to load
https://pagure.io/fedora-infrastructure/issues in my browser and it does
not work, it just waits for response :/

~~~

$ curl https://pagure.io/fedora-infrastructure/issues -o /dev/null
  % Total    % Received % Xferd  Average Speed   Time    Time Time 
Current
 Dload  Upload   Total   Spent    Left 
Speed
100  107k  100  107k    0 0  30755  0  0:00:03  0:00:03 --:--:--
30764


$ traceroute pagure.io
traceroute to pagure.io (152.19.134.147), 30 hops max, 60 byte packets
 1  _gateway (192.168.0.1)  3.274 ms  4.385 ms  4.320 ms
 2  * * *
 3  ip-86-49-1-161.net.upcbroadband.cz (86.49.1.161)  22.197 ms  22.094
ms  22.066 ms
 4  cz-brn-pop40-ra2-vla2191.net.upc.cz (84.116.220.246)  121.057 ms 
124.204 ms  124.182 ms
 5  cz-brn-pop40-ra1-vla2110.net.upc.cz (84.116.221.41)  126.583 ms 
126.456 ms  126.449 ms
 6  cz-prg01a-ra4-vla2109.net.upc.cz (84.116.221.37)  126.402 ms 
111.096 ms  116.115 ms
 7  de-fra04a-rc1-ae33-0.aorta.net (84.116.135.5)  110.803 ms  137.982
ms  137.875 ms
 8  de-fra04d-rc1-ae26-0.aorta.net (84.116.138.238)  137.842 ms  137.777
ms  137.724 ms
 9  * * *
10  us-nyc01b-rd2-ae9-0.aorta.net (84.116.140.170)  138.336 ms  138.298
ms  115.267 ms
11  us-nyc01b-ri2-ae3-0.aorta.net (84.116.137.194)  114.465 ms  112.698
ms  110.019 ms
12  nyc2-brdr-01.inet.qwest.net (63.235.40.165)  136.127 ms  136.117 ms 
136.086 ms
13  dca-edge-23.inet.qwest.net (67.14.6.158)  159.519 ms  159.547 ms 
161.527 ms
14  65.120.78.78 (65.120.78.78)  136.700 ms  135.992 ms  135.886 ms
15  uncmanning-to-rtp-ip-asr-gw.ncren.net (128.109.19.90)  132.844 ms 
137.504 ms  136.760 ms
16  core-m-v1214.net.unc.edu (152.19.255.66)  135.283 ms  136.117 ms 
138.533 ms
17  152.19.255.70 (152.19.255.70)  128.737 ms  128.655 ms  128.518 ms
18  152.19.255.166 (152.19.255.166)  147.476 ms  132.950 ms  137.336 ms
19  vmhost1-rsa.fedora.ibiblio.org (152.19.134.147)  126.626 ms !X 
130.794 ms !X  121.215 ms !X
~~~


The strange thing is that the pagure title page or the project overview
can be loaded just fine and neither the tools above shows any suspicious
behavior to me.


Vít


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

Re: FBR: Disable Bodhi batching

2018-03-27 Thread Vít Ondruch

So what does the "push to batched" button doing now?


V.


Dne 26.3.2018 v 20:46 Randy Barlow napsal(a):
> This is now deployed to production.
> ___
> infrastructure mailing list -- infrastructure@lists.fedoraproject.org
> To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org

Re: integrate dist-git and bugzilla more tightly

2018-01-10 Thread Vít Ondruch



Dne 10.1.2018 v 01:09 Dusty Mabe napsal(a):
>
> I go to a dist-git repo and find a bug when browsing the source code.
> I can
> open a PR to fix it, but what if I don't know how to fix it? I open an
> issue, right?
>
> Except, there's no issue tracker for dist-git pagure repos. That's
> what bugzilla
> is for. Now I need to go to bugzilla, find the component, fill out a
> bug, yada yada.
>
> I understand the need for bugzilla and that it's not going away
> anytime soon, but could
> we possibly integrate dist-git pagure issue tracking and bugzilla in a
> way that makes
> the whole process more seamless for this workflow. We could even use
> the bugzilla API
> and display things differently in pagure if we wanted.
>
> These are just suggestions. I feel like this can be improved.
>
> Dusty

On the overview page, there is  "bug reports" link, is this not enough?


Vít



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

Re: [release] - fedora-packages 4.0.0

2018-01-02 Thread Vít Ondruch

ruby and rubygems packages are finally not mixed up. That is great. Thanks!


Vít


Dne 22.12.2017 v 19:09 Clement Verna napsal(a):
> Greetings,
>
> As an early Christmas present, a new release of fedora-packages is available.
>
> The changelog is available in here[0].
>
> Thanks to Patrick, it is currently deployed in stg and prod.
>
> Happy Holidays.
>
> [0] - 
> https://github.com/fedora-infra/fedora-packages/blob/develop/CHANGELOG.rst#400
>
> Clément
> ___
> infrastructure mailing list -- infrastructure@lists.fedoraproject.org
> To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org

Re: Bodhi 2.10.1 in production

2017-08-23 Thread Vít Ondruch



Dne 23.8.2017 v 10:54 Pierre-Yves Chibon napsal(a):
> On Wed, Aug 23, 2017 at 10:49:22AM +0200, Vít Ondruch wrote:
>>
>> Dne 23.8.2017 v 10:40 Pierre-Yves Chibon napsal(a):
>>> On Wed, Aug 23, 2017 at 10:22:00AM +0200, Vít Ondruch wrote:
>>>> Dne 22.8.2017 v 21:42 Jeremy Cline napsal(a):
>>>>> Hey folks,
>>>>>
>>>>> Bodhi 2.10.1 is now running in production.
>>>>>
>>>>> The change log: https://bodhi.fedoraproject.org/docs/release_notes.html
>>>>>
>>>>> At this time, the Greenwave integration is configured to be off. When
>>>>> Greenwave is ready, we'll be able to flip on the integration.
>>>> Greenwave? What is that?
>>> https://pagure.io/greenwave/
>>>
>>> It is the tool that will make the decision of gating or not an update based 
>>> on
>>> automated test results.
>> Ah, thx.
>>
>> I wish this was already in Rawhide ... But may be it will be?
> The gating is done in bodhi, so for this we would need to make rawhide go
> through bodhi (which I still think would be a good idea

I am +1 on this!

Vít

>  and if it's all
> automatic the only drawback would be that builds actually land in rawhide a
> little later than they do today)
>
> Pierre
>
>
> ___
> infrastructure mailing list -- infrastructure@lists.fedoraproject.org
> To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org



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

Re: Bodhi 2.10.1 in production

2017-08-23 Thread Vít Ondruch



Dne 23.8.2017 v 10:40 Pierre-Yves Chibon napsal(a):
> On Wed, Aug 23, 2017 at 10:22:00AM +0200, Vít Ondruch wrote:
>>
>> Dne 22.8.2017 v 21:42 Jeremy Cline napsal(a):
>>> Hey folks,
>>>
>>> Bodhi 2.10.1 is now running in production.
>>>
>>> The change log: https://bodhi.fedoraproject.org/docs/release_notes.html
>>>
>>> At this time, the Greenwave integration is configured to be off. When
>>> Greenwave is ready, we'll be able to flip on the integration.
>> Greenwave? What is that?
> https://pagure.io/greenwave/
>
> It is the tool that will make the decision of gating or not an update based on
> automated test results.

Ah, thx.

I wish this was already in Rawhide ... But may be it will be?


Vít



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

Re: Bodhi 2.10.1 in production

2017-08-23 Thread Vít Ondruch



Dne 22.8.2017 v 21:42 Jeremy Cline napsal(a):
> Hey folks,
>
> Bodhi 2.10.1 is now running in production.
>
> The change log: https://bodhi.fedoraproject.org/docs/release_notes.html
>
> At this time, the Greenwave integration is configured to be off. When
> Greenwave is ready, we'll be able to flip on the integration.

Greenwave? What is that?


Vít



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

Re: The future of pkgdb

2017-04-28 Thread Vít Ondruch



Dne 28.4.2017 v 12:27 Ryan Lerch napsal(a):
>
> On Fri., 28 Apr. 2017 at 6:05 pm, Vít Ondruch <vondr...@redhat.com
> <mailto:vondr...@redhat.com>> wrote:
>
>
>
> Dne 28.4.2017 v 07:34 Chenxiong Qi napsal(a):
> > On Wed, Apr 26, 2017 at 2:54 PM, Pierre-Yves Chibon
> <pin...@pingoured.fr <mailto:pin...@pingoured.fr>> wrote:
> >> On Wed, Apr 26, 2017 at 11:29:28AM +0800, Chenxiong Qi wrote:
> >>>
> >>> On 04/25/2017 10:23 PM, Pierre-Yves Chibon wrote:
> >>>> (adding the releng list on CC, please keep the reply on the
> infra list)
> >>>>
> >>>>
> >>>> Hi Everyone,
> >>>>
> >>>> Following up on the thread about pagure on the top of
> dist-git started a
> >>>> few days ago Ralph Bean, Matthew Prahl and I had a quick
> meeting just a few
> >>>> minutes ago about the future of pkgdb.
> >>>>
> >>> Will pkgdb go away? It looks Pagure would be a data store
> combining package
> >>> repositories and pkgdb data together. From my point of view,
> pkgdb could
> >>> still sit between packagers and Pagure rather than exposing
> lower level data
> >>> directly as an interface of package data (whatever it comes
> from Pagure or
> >>> PDC) to packagers and existing tools like pkgdb-cli. If
> anything of my
> >>> understand about current pkgdb is not accurate, just scratch
> my thought :)
> >> The idea is indeed to retire pkgdb. However, I'm not sure I
> follow why you would
> >> prefer to keep it and what you don't like about dropping it.
> Could you expand
> >> your thoughts a little more?
> > I thought "pkgdb" would become a main interface for anyone who wants
> > to lookup package information without need to interact with
> Pagure or
> > PDC directly, meanwhile we can keep using current terms about
> packages
> > e.g. main contacts, that would be easier for anyone to get involved
> > and start to contribute.
>
> I support this. For me is the pkgdb entry point. If I want to know
> something about package, I'm going to take a look into pkgdb. I'll be
> missing its simple UI.
>
>
> Vít
>
>
> There is also the packages app that provides information on packages
>
> https://apps.fedoraproject.org/packages/kernel

I know ... but honestly, this one is unusable ... starting by the ton of
slow javascript which often fails, ending with wrong information such as
https://apps.fedoraproject.org/packages/rubygems/


Vít

>
> --ryanlerch
>
>
>
> >
> > Will current pkgdb API[1] be still available, or need to query from
> > Pagure or PDC individually?
> >
> > Actually, I don't insist on not drop pkgdb. Whatever it'll be
> dropped
> > or not and whatever the form it will be, as long as it could make
> > things easier for packagers and potential contributors. :)
> >
> > [1] https://admin.fedoraproject.org/pkgdb/api/
> >
> >> Thanks,
> >> Pierre
> >>
> >> ___
> >> infrastructure mailing list --
> infrastructure@lists.fedoraproject.org
> <mailto:infrastructure@lists.fedoraproject.org>
> >> To unsubscribe send an email to
> infrastructure-le...@lists.fedoraproject.org
> <mailto:infrastructure-le...@lists.fedoraproject.org>
> >>
> >
> >
> ___
> infrastructure mailing list --
> infrastructure@lists.fedoraproject.org
> <mailto:infrastructure@lists.fedoraproject.org>
> To unsubscribe send an email to
> infrastructure-le...@lists.fedoraproject.org
> <mailto:infrastructure-le...@lists.fedoraproject.org>
>
>
>
> ___
> infrastructure mailing list -- infrastructure@lists.fedoraproject.org
> To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org

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

Re: The future of pkgdb

2017-04-28 Thread Vít Ondruch



Dne 28.4.2017 v 07:34 Chenxiong Qi napsal(a):
> On Wed, Apr 26, 2017 at 2:54 PM, Pierre-Yves Chibon  
> wrote:
>> On Wed, Apr 26, 2017 at 11:29:28AM +0800, Chenxiong Qi wrote:
>>>
>>> On 04/25/2017 10:23 PM, Pierre-Yves Chibon wrote:
 (adding the releng list on CC, please keep the reply on the infra list)


 Hi Everyone,

 Following up on the thread about pagure on the top of dist-git started a
 few days ago Ralph Bean, Matthew Prahl and I had a quick meeting just a few
 minutes ago about the future of pkgdb.

>>> Will pkgdb go away? It looks Pagure would be a data store combining package
>>> repositories and pkgdb data together. From my point of view, pkgdb could
>>> still sit between packagers and Pagure rather than exposing lower level data
>>> directly as an interface of package data (whatever it comes from Pagure or
>>> PDC) to packagers and existing tools like pkgdb-cli. If anything of my
>>> understand about current pkgdb is not accurate, just scratch my thought :)
>> The idea is indeed to retire pkgdb. However, I'm not sure I follow why you 
>> would
>> prefer to keep it and what you don't like about dropping it. Could you expand
>> your thoughts a little more?
> I thought "pkgdb" would become a main interface for anyone who wants
> to lookup package information without need to interact with Pagure or
> PDC directly, meanwhile we can keep using current terms about packages
> e.g. main contacts, that would be easier for anyone to get involved
> and start to contribute.

I support this. For me is the pkgdb entry point. If I want to know
something about package, I'm going to take a look into pkgdb. I'll be
missing its simple UI.


Vít

>
> Will current pkgdb API[1] be still available, or need to query from
> Pagure or PDC individually?
>
> Actually, I don't insist on not drop pkgdb. Whatever it'll be dropped
> or not and whatever the form it will be, as long as it could make
> things easier for packagers and potential contributors. :)
>
> [1] https://admin.fedoraproject.org/pkgdb/api/
>
>> Thanks,
>> Pierre
>>
>> ___
>> infrastructure mailing list -- infrastructure@lists.fedoraproject.org
>> To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
>>
>
>
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org

Re: The future of pkgdb

2017-04-28 Thread Vít Ondruch



Dne 25.4.2017 v 21:54 Jason L Tibbitts III napsal(a):
>> "KF" == Kevin Fenzi  writes:
> [Using foo-owner@fp.o as the default owner for bugs]
> KF> But also disadvantages of people liking to see a name they can point
> KF> to about the package or know who is cc'ed on the bug.
>
> For years I've wondered why we don't do that, honestly.  But I think it
> might be weird that bugzilla separates the owner of a package from the
> owner of a bug, and some of the interactions might be non-obvious.
>
> When I take a bug, will the other maintainers still be notified?  Will
> bugzilla send mail to foo-owner as well as CC'ing the maintainers, so
> that everyone gets each message twice?
>
> Will someone be able to log into bugzilla as foo-owner?
>
> What happens to bugs marked as private?  If they're private to foo-owner
> then how will the actual maintainers see them?

I had similar question about FAS groups ... here is my PR which may
answer some of your questions:

https://github.com/fedora-infra/pkgdb2/pull/414

While you are adding several interesting questions on top of that :)


Vít
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org

Re: COPR and new chroot naming

2017-02-21 Thread Vít Ondruch

I honestly don't understand what is purpose of the f26 vs master. Why we
have empty master currently (speaking of dist-git)? master should be the
same as rawhide, as it is in Fedora.


Vít


Dne 21.2.2017 v 10:05 Michal Novotny napsal(a):
> Hello folks,
>
> We have quite recently changed naming of rawhide chroot to fXY in COPR
> and I would like to know your opinion about it.
>
> As branching is behind the door, I tried to consider it again and
> slightly changed my mind. The main problem with just fXY is that it is
> probably not very intuitive. "rawhide" tells clearly that rawhide
> repos are used whereas with just fXY, the repos used for the chroot
> need to be switched at branching (from rawhide to the fXY ones).
>
> We were probably trying to be too fancy here thinking that the
> follow-up features (all package rebuilding and chroot forking) will
> complement it well. These features can, however, work with both
> namings and the "rawhide" chroot just plays much better with mock and
> how it introduces the new chroot configs.
>
> We can go either way but to me the "just-call-it-rawhide" seems to be
> more simple now while also providing nicer user experience.
>
> clime
>
>
>
>
>
>
>
>
> ___
> infrastructure mailing list -- infrastructure@lists.fedoraproject.org
> To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org

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

Re: Need some advice

2017-02-13 Thread Vít Ondruch

One advice is to use $SUBJECT which is more descriptive. Thx 


Vít


Dne 12.2.2017 v 22:34 Mark Morris napsal(a):
> Hi Guys 
>
> Just need a quick bit of advice, I have created a VM so I can use some
> of the tools and software that is used I have installed ansible and
> bookmarked the documentation for it, is there anything else I should be
> looking at and adding to my VM?
>
> Thanks
>
> Mark
> ___
> infrastructure mailing list -- infrastructure@lists.fedoraproject.org
> To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org

Re: The Future of Ask Fedora (potentially: hosted by upstream)

2016-12-16 Thread Vít Ondruch



Dne 15.12.2016 v 17:13 Matthew Miller napsal(a):
> On Thu, Dec 15, 2016 at 10:57:44AM -0500, Stephen John Smoogen wrote:
>> Which loops us back to the original. The upstream is trying to make
>> this an open source product where they are paid for their time to work
>> on this by organizations who are using said product.
>  which is fine, but Fedora isn't really in a position to sponsor
> work in that way.
>

Can Red Hat hire him? ;)


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

Re: Planned Outage: fedorainfracloud.org - 2016-07-22 02:00 UTC

2016-07-22 Thread Vít Ondruch

If it had been planned, why it was announced just like 3h in advance? :/


Vít



Dne 21.7.2016 v 21:25 Patrick Uiterwijk napsal(a):
> Planned Outage: fedorainfracloud.org - 2016-07-22 02:00 UTC
>
> There will be an outage starting at 2016-07-22 02:00 UTC, which will
> last approximately 4 hours.
>
> To convert UTC to your local time, take a look at
> http://fedoraproject.org/wiki/Infrastructure/UTCHowto or run:
>
> date -d '2016-07-22 02:00 UTC'
>
> Reason for outage:
>
> We will be updating our OpenStack? cloud, which will require all cloud
> instances to be rebooted. The storage failover will also be tried
> again to verify that the storage redundancy is restored.
>
> Affected Services:
>
> fedorainfracloud.org copr.fedoraproject.org fedoramagazine.org
> taiga.fedorainfracloud.org testdays.fedorainfracloud.org
> jenkins.fedorainfracloud.org
>
> various development instances
>
> Contact Information:
>
> Ticket Link: https://fedorahosted.org/fedora-infrastructure/ticket/5410
>
> Please join #fedora-admin or #fedora-noc on irc.freenode.net or add
> comments to the ticket for this outage above.
> ___
> infrastructure mailing list
> infrastructure@lists.fedoraproject.org
> https://lists.fedoraproject.org/admin/lists/infrastructure@lists.fedoraproject.org

___
infrastructure mailing list
infrastructure@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/infrastructure@lists.fedoraproject.org

Re: Breaking distgit-stg

2016-07-20 Thread Vít Ondruch

BTW is forking supported? Tried to fork the ruby repository and it
failed ... "Fatal Error (500)".


Vít



Dne 19.7.2016 v 18:12 Pierre-Yves Chibon napsal(a):
> Good Morning Everyone,
>
> As part of his Google Summer of Code Vivek Anand has been working on adjusting
> pagure so that it would fit our needs to run it on the top of distgit.
>
> All the changes have been merged now and our cloud instance is looking quite
> good: http://209.132.184.205/
>
> So I would like to hereby request the permission to break distgit in stg by
> dropping cgit and replacing http://pkgs.stg.fedoraproject.org/ by pagure,
> or maybe more http://pkgs.fedoraproject.org/pagure/ by pagure so that it 
> doesn't
> block accessing the other endpoints available at pkgs.fp.o.
>
> Thoughts?
>
> Thanks,
> Pierre
>
>
>
> ___
> infrastructure mailing list
> infrastructure@lists.fedoraproject.org
> https://lists.fedoraproject.org/admin/lists/infrastructure@lists.fedoraproject.org

___
infrastructure mailing list
infrastructure@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/infrastructure@lists.fedoraproject.org

Re: Breaking distgit-stg

2016-07-20 Thread Vít Ondruch



Dne 19.7.2016 v 18:12 Pierre-Yves Chibon napsal(a):
> dropping cgit and replacing http://pkgs.stg.fedoraproject.org/ by pagure,

Can't they live side by side during some testing period? It probably may
provide some transition period  Just thinking loud :)

Otherwise, I very appreciate the use of Pagure instead of cgit ;) Thank
you for doing that.


Vít
___
infrastructure mailing list
infrastructure@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/infrastructure@lists.fedoraproject.org

Re: Setting up development environment for Fedora Web Portal

2016-03-15 Thread Vít Ondruch

You probably want to contact developer portal folks at their ML:

developer-por...@lists.fedoraproject.org

But I adding some of them on BCC, so they might get back to you.


Vít



Dne 15.3.2016 v 08:40 Dimuthu Lakmal napsal(a):
> Hi, 
> I was setting up development environment for fedora web-portal
> I followed guidlines provided in 
> https://github.com/developer-portal/website/blob/master/DEVELOPMENT.md and 
> used Vagrant method. When i execute jekyll serve --force_polling -H 0.0.0.0 
> command, it says there are some missing files in content folder. But actually 
> files are in there. any solution?
> ___
> infrastructure mailing list
> infrastructure@lists.fedoraproject.org
> http://lists.fedoraproject.org/admin/lists/infrastructure@lists.fedoraproject.org
___
infrastructure mailing list
infrastructure@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/infrastructure@lists.fedoraproject.org

Broken links?

2015-11-24 Thread Vít Ondruch

It seems that the links to ML are broken after migration to HyperKitty.
For example, in this ticket [1], there is referenced this link [2]. The
link says "2013-December", but when I open it, I got this email [3]. 
The email is from January 2014 and moreover, it is definitely not the
one I would expect by context of the topic. The link should very likely
reference the email [4], but hard to guess now :/


Vít




[1] https://fedorahosted.org/fpc/ticket/398
[2]
https://lists.fedoraproject.org/pipermail/packaging/2013-December/009899.html
[3]
https://lists.fedoraproject.org/archives/list/packaging%40lists.fedoraproject.org/message/LNCKCOXG4CDT3ODYPRAW6RJI2JXR2SWV/
[4]
https://lists.fedoraproject.org/archives/list/packaging%40lists.fedoraproject.org/thread/GIAH53L6LD6ALSIGG75YSIKXCLN7JGFB/
___
infrastructure mailing list
infrastructure@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/infrastructure@lists.fedoraproject.org

Re: [release] fedora-packages: 3.0.1

2015-11-23 Thread Vít Ondruch

Sorry, but I'm not really sure it works as expected looking at:

https://apps.fedoraproject.org/packages/ruby

it says "ruby - subpackage of rubygems" which is definitely not true.


Vít




Dne 23.11.2015 v 15:45 Ralph Bean napsal(a):
> Hey all, after the deployment of 3.0.0 on Thursday[1], I have a followup
> release here with some minor bugfixes and enhancements.
>
> [1] - http://threebean.org/blog/history-of-fedora-packages/
>
> 3.0.1
> -
>
> Pull Requests
>
> - (@ralphbean)  #204, Log a warning, but don't email us.
>   https://github.com/fedora-infra/fedora-packages/pull/204
> - (@ralphbean)  #199, Fix icon suffix.
>   https://github.com/fedora-infra/fedora-packages/pull/199
> - (@ralphbean)  #201, Remove broken/unused rhbz stuff.
>   https://github.com/fedora-infra/fedora-packages/pull/201
> - (@ralphbean)  #202, Fix .spec pygments lexer.
>   https://github.com/fedora-infra/fedora-packages/pull/202
> - (@ralphbean)  #203, Fix git scraping.
>   https://github.com/fedora-infra/fedora-packages/pull/203
> - (@ralphbean)  #207, Remove rhel5 links.
>   https://github.com/fedora-infra/fedora-packages/pull/207
> - (@ralphbean)  #208, Change text from Owner to Point of Contact.
>   https://github.com/fedora-infra/fedora-packages/pull/208
> - (@ralphbean)  #200, Fix up links to bodhi and koji.
>   https://github.com/fedora-infra/fedora-packages/pull/200
>
> Commits
>
> - 600480058 Raise a keyerror just to make this simpler.
>   https://github.com/fedora-infra/fedora-packages/commit/600480058
> - 0c5ab0a58 Move xapian document preparation out of the threadpool.  The 
> bindings aren't threadsafe on el6.
>   https://github.com/fedora-infra/fedora-packages/commit/0c5ab0a58
> - a891c2938 Also, log, so we know where we are on the fan-in thread.
>   https://github.com/fedora-infra/fedora-packages/commit/a891c2938
> - 7202059f4 Fix icon suffix.
>   https://github.com/fedora-infra/fedora-packages/commit/7202059f4
> - 1dfb63dbb Add build links on the Active Releases page.
>   https://github.com/fedora-infra/fedora-packages/commit/1dfb63dbb
> - 777f0ea55 Make koji builds a link to koji.
>   https://github.com/fedora-infra/fedora-packages/commit/777f0ea55
> - 1651a67a4 Remove broken/unused rhbz stuff.
>   https://github.com/fedora-infra/fedora-packages/commit/1651a67a4
> - e4e6cb79e Fix .spec pygments lexer.
>   https://github.com/fedora-infra/fedora-packages/commit/e4e6cb79e
> - 6d9dd0da7 Fix git scraping.
>   https://github.com/fedora-infra/fedora-packages/commit/6d9dd0da7
> - 84ddb19a4 Log a warning, but don't email us.
>   https://github.com/fedora-infra/fedora-packages/commit/84ddb19a4
> - dcdeaaf90 Remove rhel5 links.  Fixes #205.
>   https://github.com/fedora-infra/fedora-packages/commit/dcdeaaf90
> - 954b76de3 Change text from Owner to Point of Contact.
>   https://github.com/fedora-infra/fedora-packages/commit/954b76de3
> ___
> infrastructure mailing list
> infrastructure@lists.fedoraproject.org
> http://lists.fedoraproject.org/admin/lists/infrastructure@lists.fedoraproject.org
___
infrastructure mailing list
infrastructure@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/infrastructure@lists.fedoraproject.org

Re: [PATCH] koji directory cleanup: shorten the time we keep things

2015-10-26 Thread Vít Ondruch

Dne 23.10.2015 v 23:18 den...@ausil.us napsal(a):
> keep koschei builds for 1 day

This is really short period. If the build fails Friday evening, it is
already long time lost Monday morning when I would like to check what
went wrong 



Vít

___
infrastructure mailing list
infrastructure@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/infrastructure@lists.fedoraproject.org

Re: Dist Git for Copr

2015-05-06 Thread Vít Ondruch

Dne 6.5.2015 v 12:31 Adam Samalik napsal(a):
   Branch name: 'epel-7', 'fedora-22'



Can we stick to Fedora's dist-git branch name conventions please?


Thanks


Vít
___
infrastructure mailing list
infrastructure@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/infrastructure

Re: Upcoming Mirrormanager 2 production deployment

2015-04-27 Thread Vít Ondruch

Dne 24.4.2015 v 19:32 Kevin Fenzi napsal(a):
 https://admin.stg.fedoraproject.org/mirrormanager2/


 https://mirrors.stg.fedoraproject.org/



Should there be any difference between these two links? Opening them in
browser, I endup at:

https://admin.stg.fedoraproject.org/mirrormanager2/

and

https://admin.stg.fedoraproject.org/mirrormanager2///

respectively.


And what is Fedora 64 and RHEL 7? Is this just due to some testing data?



Vít
___
infrastructure mailing list
infrastructure@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/infrastructure

Re: [release] pkgdb2 1.24

2015-03-24 Thread Vít Ondruch

Dne 24.3.2015 v 08:45 Pierre-Yves Chibon napsal(a):
 On Tue, Mar 24, 2015 at 08:20:13AM +0100, Vít Ondruch wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Is the Request new package [1] now officially supported? 
 Yes it is :)

 Will there be some announcement?
 I have to write a blog post to announce it, get some people to test and then 
 in
 a near future we will deprecate the current process in favor of the new one.


great :) thx

 And will it work faster/automatically or is there still
fallback to some manual action?
 I doubt it will be faster for new package or new branch.

In other words there is still some manual process in background, so we
have to wait for some person to do the stuff. Just want to set my
expectations properly ;-P

 The only place where it will be faster if for new *fedora* branch request if 
 the
 requester is a package admin (ie: has approveacls).

And I have one additional RFE. Since there is referred bugzilla ticket, I
believe that you should be able to get the package name and summary
from that ticket summary. This would save me from copy-pasting.
 I don't think we'll do this for a couple of reasons:
 - subject lines regularly have errors, so this is one last place where people
   can adjust

Or make new mistakes, depends on point of view ;)

 - the idea is not to put in pkgdb code that is bugzilla-specific especially
   since we want to move package review off bugzilla.

I am still sad about the unnecessary duplication of all the information :/

I believe that the only information you need to create the package is
the BZ ticket or the package name (depends which way you take) and
branches. The rest should be removed, since you can obtain the
information from the package. I understand there is some while between
the package is build and the information is refreshed etc, but I would
prefer to miss the information in pkgdb for some while then to copy
paste it around again and again.


[1] https://admin.fedoraproject.org/pkgdb/request/package/
 As usual, thanks for all your testing :)

YAW


Vít


___
infrastructure mailing list
infrastructure@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/infrastructure

Re: [release] pkgdb2 1.24

2015-03-24 Thread Vít Ondruch


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Is the Request new package [1] now officially supported? Will there be
some announcement? And will it work faster/automatically or is there
still fallback to some manual action?

And I have one additional RFE. Since there is referred bugzilla ticket,
I believe that you should be able to get the package name and
summary from that ticket summary. This would save me from copy-pasting.


Vít


[1] https://admin.fedoraproject.org/pkgdb/request/package/



Dne 23.3.2015 v 18:57 Pierre-Yves Chibon napsal(a):
 On Thu, Mar 19, 2015 at 02:55:15PM +0100, Pierre-Yves Chibon wrote:
 Hi all,

 I have just released and pushed to staging a new pkgdb2 release: 1.24
 Here is the changelog for this version:

 * Thu Mar 19 2015 Pierre-Yves Chibon pin...@pingoured.fr - 1.24-1
 - Fix orphaning package having a group as PoC
 - Fix excluding provenpackager from some packages specified in the
   configuration
 - Monkey patch flask.jsonify to handle JSONP responses on GET
requests (Ralph
   Bean)
 - Anitya integration
 - Allow package admins to retire a package


 Here below is the changelog for the versions that made it to stg but
not prod
 (giving more info about the changes that are specific to stg).

 * Fri Feb 20 2015 Pierre-Yves Chibon pin...@pingoured.fr - 1.23.995-1
 - Update to 1.23.995 (pre-release of 1.24)
 - Fix the link to `My Requests` on the API documentation page

 * Fri Feb 20 2015 Pierre-Yves Chibon pin...@pingoured.fr - 1.23.994-1
 - Update to 1.23.994 (pre-release of 1.24)
 - Do not use insecure connection to pkgdb in set_monitoring_status
(Till Maas)
 - Add documentation for the API endpoint to set the monitoring status
of a
   package
 - Replace the monitoring toggle button by one that might be clearer
 - Fix actually setting the monitoring flag of new package to True
(and adjust
   the tests for this)

 * Thu Feb 19 2015 Pierre-Yves Chibon pin...@pingoured.fr - 1.23.993-1
 - Update to 1.23.993 (pre-release of 1.24)
 - Drop the package name from the URL to edit a request (fix few bugs
in the
   process)
 - If requested is a package admin, request is set to Awaiting Review
 - Use secure=True against prod pkgdb in set_monitoring_status.py
(Ralph Bean)

 * Wed Feb 18 2015 Pierre-Yves Chibon pin...@pingoured.fr - 1.23.992-1
 - Update to 1.23.992 (pre-release for 1.24)
 - Add a `My Request` tab in the main menu
 - Adjust copyright year in the master template
 - Monitor package set as True by default (Ralph Bean)
 - Drop the branch from field when requesting branch for a package
 - Add the possibility to Edit one's request directly via the `My
Requests` page
 - Increase the width of the field in the form to request a new package

 * Tue Feb 17 2015 Pierre-Yves Chibon pin...@pingoured.fr - 1.23.991-1
 - Update to 1.23.991 (pre-release for 1.24)
 - Fix documentation to reflect the correct variable name
 - Add a link to the request made by someone on the user's page (where
all the
   packages of that person are listed)
 - Simplify the form to request a package to be added to pkgdb
 - Ensure we check that a group is valid before giving it some ACLs
 - Make it easier to change one's avatar by simply clicking on it
(Ralph Bean)
 - Add a placeholder for the Review URL field when requesting a
package to be
   added to pkgdb
 - When giving watch* ACLs to a FAS user, check that this user exists
 - Per FESCo decision, Fedora branch requests will have by default a 7
days
   period during which packager with approveacls will be allowed to
grant/deny
   the request, this period does not apply if the requester has
approveacls on
   the package

 * Mon Jan 26 2015 Pierre-Yves Chibon pin...@pingoured.fr - 1.23.99-1
 - Update to 1.23.99 (pre-release for 1.24)
 - New processes to request a new package or a new branch of a package
directly
   in pkgdb instead of relying on bugzilla


 1.24 is now running in prod.
 I have had to adjust some permissions at the DB level and hopefully I
got them
 all, but please do report if you run into an error 500.

 Thanks,
 Pierre


 ___
 infrastructure mailing list
 infrastructure@lists.fedoraproject.org
 https://admin.fedoraproject.org/mailman/listinfo/infrastructure

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBAgAGBQJVERAsAAoJEAzgnueZF7h89hsP/RX3yxQblWr22Zmen0w5DXC3
tBpW60946QdDzUq2pLbRqq9rM3iqQiFsjbX4QzxXT8JXlwQO8kqjGNHwQlzuXLUW
lX9B2J8RYnOPP9krDX3Y4MRZmhV4jL4lIZjXgAwCyrxH0avJZk2tykpIcgzgeXY+
HRuZ//r49FLXQ04ihMZfe5aN15Fqwp8caaZ0Q1QKS9Rqb9u0jRZPaWq74c/NSxvg
N68bxaab2wxtGlZkt6CfakQkHybLyZ54uVK/CG2ulnuM0x59eTmHdCh/Hrlnscje
rMinRSCdD1j+vn3dTZZmjIwcRla6F8H6KDa9vpuAEy/56zDTE4vYJuoJsusn2Dc8
GIlLC5YLXYSirBUmO9qh8IjywepvSaHN1JbiFj7Hb/vLDcBGHHcEOqPrQddEJE2x
TkEcvtIIxl2OV+8Q2cIerdmcddKHFpeO+zX7lmfVUqjWFvjgn2/m73nOwXlhytFK
T5rnAPHyONzjkecl61jdFh+1rBodbn+xQqkdCKT4nGhmhI9DvCAVcLBliVpd49Nm
QLFP47FZewJV+eUYwSpyO1LP45W3iMUY9RTazgRR+6OiJTJIgiZOnIR4Sj7/heax

Re: [release] pkgdb2 1.23.995

2015-02-20 Thread Vít Ondruch


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Dne 20.2.2015 v 16:47 Pierre-Yves Chibon napsal(a):

 - Replace the monitoring toggle button by one that might be clearer


Beauty, thx :)


Vít
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBAgAGBQJU51jTAAoJEAzgnueZF7h8TUgP/1Si44BmqqJylHcM0aiJvje6
Pf1KCmDHQtm/WxSfeNWBQK2evs32nlHvSQetCzxN24aUs/ZB7daPLncgvwYsFxE3
zXY+y8hgxfwjFZzCy2n+QPdwwkeRo/Za4T5oIfXFgZETHLI5SaQB3wyt4u6Deeeq
5eldevmt0a0yD2mk1qrXbqpsidKDc2E2P49l4eTv1fXpR3NHGe+a5cdNuyQVdnJJ
aKntm67KGIreVqQXwpxHI12XUiFqzvGD4ppRNGrkNIq35q0w/6AJCP2VvH17WjAW
E4kUXdTyby1j4/FCWoFGt0Bc0lOAuwEPW/NblE1fU5KeDqdsHwGoR1vSwKdoCqQK
uEGX/yHmxZqJmHRuXb8utRwWEls/BUDSTwMO3Ms/pDbPaQXbQhtQ4ntgc0T7ctcV
5nnApUnt7iR9gCrbIDuDMIR3lxdog9dyEM0HkfGtG2o2JahMICfLJNsyk2A1PIn4
4qA3bSRXMVyMdMSVnWUhBvDYPECQC+ICsf5bxlce30Vv16JuTDWugtDuNXCXDbim
FMEtQs5b5b5X9g/zdd4z0Y2QRHE/ytK8NpFOtnwoGDAmBksLd8LEiIl+4OPMJtSH
cqj7UXkKG7aMHEs9Kjh9skvsx3Ps2qud25Lxxub/Iz/25acr4yED42nZKUuXmoV6
443LZawvK9w0iDsWmgHd
=fLAq
-END PGP SIGNATURE-

___
infrastructure mailing list
infrastructure@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/infrastructure

Re: [release] pkgdb2 1.23.992

2015-02-19 Thread Vít Ondruch


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

After setting the state to Awaiting Review, I am redirected to the
package page. I'd expect to be back in My requests page or back to the
specific request.

This leads me to idea if there should be the current package requests
displayed somewhere on package summary page? If I display rubygem-abrt
package [1], there is not visible that the branches are about to change
soon. Or that I should probably react on something.


Vít


[1] https://admin.stg.fedoraproject.org/pkgdb/package/rubygem-abrt/

Dne 19.2.2015 v 10:12 Pierre-Yves Chibon napsal(a):
 Hi everyone,

 One release aways keeps the doctor away (and Vít busy :)), so here is
the new
 one: 1.23.993

 Changelog:
 * Thu Feb 19 2015 Pierre-Yves Chibon pin...@pingoured.fr - 1.23.993-1
 - Update to 1.23.993 (pre-release of 1.24)
 - Drop the package name from the URL to edit a request (fix few bugs
in the
   process)
 - If requested is a package admin, request is set to Awaiting Review
 - Use secure=True against prod pkgdb in set_monitoring_status.py
(Ralph Bean)

 Hopefully this fixes all/most of the bugs Vít faced.

 Thanks,
 Pierre


 ___
 infrastructure mailing list
 infrastructure@lists.fedoraproject.org
 https://admin.fedoraproject.org/mailman/listinfo/infrastructure

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBAgAGBQJU5azbAAoJEAzgnueZF7h80SsQAIAO1lNCVEWKZmpwtqo7MSNd
5J7B/Z++mNrEPJMDbkGlDx0P3e1hrK45iGad+Tlv+DsgOTChoAkHKsjxnr2UHOAD
3JN81Dww5c0O4pkwMjz59XmxfDZopirNh/U9kJatqNzTDf/IHeZtHra915NbLW5g
qrI3E+ixLx/zTRE72CAbpidqAjouAz5TZ6mXbTg3UDoL/ooJcIQhAVhwRFMBDSDe
fo7H+zdtGNg1IUeNQg+XV+0tqqYKzS3dLM1l/Su+fYN84T1gycTVd4wBEwaGMTgH
4bAUsJ7Id9EggUp5P+Nx+jkKTCSZ1LlYCTGf0MVbekSmyy8/cDhp5RdHy7iPssxp
oRAJ+arbxpkr1fCiqi016oHJNUm5tn8KtfkuEnw773CqLtmvibI8sQXRoDVbyoMP
wELtM8XCq93+SPTRTw5WWnXQBTRahT0ApWTVo/eeZt27sOMIur+jaUk2OGMYBVjE
wjt7AcDOC4abDtTbaX9a2863fA6EV+4V/Qe+C6Gt8lOL4TdzAR9zC46GJyLtmp0K
uBWVxMEFG9xS5Z9zseV1XPbjdKTAQ20DQAqSZUU4334lldXeyqQ9LFtRKoRssV1U
ZJ1tIs5XV4K1PCE7YBgQQMZVwFoH70IqZUhclAd1wThDQfgc6MTGED/Wvqb7GXW8
ZUqzDcmn48Dvcelv0of/
=ABKm
-END PGP SIGNATURE-

___
infrastructure mailing list
infrastructure@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/infrastructure

Re: [release] pkgdb2 1.23.991

2015-02-17 Thread Vít Ondruch

Dne 17.2.2015 v 12:46 Pierre-Yves Chibon napsal(a):

 Actually now I found that I can't approve the action  That is weird.
 That cannot be true.
 The Awaiting Review is kind of the way you can approve the request

I can't set awaiting review state anywhere at

https://admin.stg.fedoraproject.org/pkgdb/package/rubygem-abrt/requests/5

The only actions available are pending or obsolete and after click
on update, it fails entirely with The requested URL was not found on
the server. error. This is the URL:

https://admin.stg.fedoraproject.org/pkgdb/package//requests/5

Which is obviously missing the rubygem-abrt part.



Vít

___
infrastructure mailing list
infrastructure@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/infrastructure

Re: [release] pkgdb2 1.23.991

2015-02-17 Thread Vít Ondruch


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Dne 17.2.2015 v 12:20 Vít Ondruch napsal(a):

 Dne 17.2.2015 v 11:44 Pierre-Yves Chibon napsal(a):
  Good morning everyone,

  I have just released and push to staging a new release of pkgdb2:
1.23.991
  (another pre-release of 1.24)

  Here is the changelog:
  * Tue Feb 17 2015 Pierre-Yves Chibon pin...@pingoured.fr - 1.23.991-1
  - Update to 1.23.991 (pre-release for 1.24)
  - Fix documentation to reflect the correct variable name
  - Add a link to the request made by someone on the user's page (where
 all the
packages of that person are listed)
  - Simplify the form to request a package to be added to pkgdb
  - Ensure we check that a group is valid before giving it some ACLs
  - Make it easier to change one's avatar by simply clicking on it
 (Ralph Bean)
  - Add a placeholder for the Review URL field when requesting a package
 to be
added to pkgdb

 The text fields are too narrow. I can't even see the entire placeholder,
 what is its content. The summary should accommodate 80 characters.


  - When giving watch* ACLs to a FAS user, check that this user exists
  - Per FESCo decision, Fedora branch requests will have by default a
7 days
period during which packager with approveacls will be allowed to
 grant/deny
the request, this period does not apply if the requester has
 approveacls on
the package

  I have one more change opened for review that will add a `My Requests`
 tab to
  the main menu (for logged in users), for the moment requests are
 accessible via
  the packager's info page, for example:
  https://admin.stg.fedoraproject.org/pkgdb/packager/vondruch/
  and
  https://admin.stg.fedoraproject.org/pkgdb/packager/vondruch/requests

 Thx, this is good start. You want be surprised if I'd like to modify the
 request now ;)

 BTW how to ask for new branch for example?


Ah, request new branch in package status ... which gives me strangely
floating and strange formated box 


Vít




 Vít


 ___
 infrastructure mailing list
 infrastructure@lists.fedoraproject.org
 https://admin.fedoraproject.org/mailman/listinfo/infrastructure

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBAgAGBQJU4ySvAAoJEAzgnueZF7h8re0P/R1ysafA3LEi9nwbunyuMmtQ
ock8Q0j4HBgE3O1GhvJ+4sDb6g4UtnTW+FYnHXz2V2B46iDFqEndKpcp3841+OHE
ojSgKdLpgYwvy65XV1gVYLXsbdgkJGKqUqBqw0FcF5uu9E+y2em6EPiLS0TPKfoH
VOoGDbW1BHwxgcwaxbRWr1rxtREwWESqrrrG5YyJHmLzMhsp4UX7AF2Dzc1fqrCX
mYAaLXBtuVIJyy9AFy9bnxkZD756jmR8OTfpD/cW+HcjdfumWSpaMT2ksxxbihDR
NArwRkI1XRCexkJdhq0TOO5Zj3sjlwmVkTywA6tcfkE0cOBWrkEzsy890K05T/1X
zcgMjmwGuI1DL8cjP1xXX3uCDmLHP2fYGTB9CQEMDXTYRR0q1WfeuL0ls9ud05lf
j6vUPJHZSe096+arT32st8WvffTSDRTMStS/2dgsAFKQVxsZ9/SVXoqAWgMl+gs5
FyROjayps+T+uxh9FQGpKDoLD4YorqxfaeaftOI0LWWwbLT8M6PTPzPFeefzPlyU
06XLESTliSV9QuAsWwO7iTry3K8f+FL7OGpaFTIpK6HyF4ys1y26S1Q5kG5dXdvt
H2+PODwhTMUhImSvPz+D6IE8yBtcEDadd5ernmSz+rMFEz7GpqYHyIUiUXhJ4whl
yyBQ6/WGRr5g1aGsDnbg
=7dbK
-END PGP SIGNATURE-

___
infrastructure mailing list
infrastructure@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/infrastructure

Re: [release] pkgdb2 1.23.991

2015-02-17 Thread Vít Ondruch


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Dne 17.2.2015 v 11:44 Pierre-Yves Chibon napsal(a):
 Good morning everyone,

 I have just released and push to staging a new release of pkgdb2: 1.23.991
 (another pre-release of 1.24)

 Here is the changelog:
 * Tue Feb 17 2015 Pierre-Yves Chibon pin...@pingoured.fr - 1.23.991-1
 - Update to 1.23.991 (pre-release for 1.24)
 - Fix documentation to reflect the correct variable name
 - Add a link to the request made by someone on the user's page (where
all the
   packages of that person are listed)
 - Simplify the form to request a package to be added to pkgdb
 - Ensure we check that a group is valid before giving it some ACLs
 - Make it easier to change one's avatar by simply clicking on it
(Ralph Bean)
 - Add a placeholder for the Review URL field when requesting a package
to be
   added to pkgdb

The text fields are too narrow. I can't even see the entire placeholder,
what is its content. The summary should accommodate 80 characters.


 - When giving watch* ACLs to a FAS user, check that this user exists
 - Per FESCo decision, Fedora branch requests will have by default a 7 days
   period during which packager with approveacls will be allowed to
grant/deny
   the request, this period does not apply if the requester has
approveacls on
   the package

 I have one more change opened for review that will add a `My Requests`
tab to
 the main menu (for logged in users), for the moment requests are
accessible via
 the packager's info page, for example:
 https://admin.stg.fedoraproject.org/pkgdb/packager/vondruch/
 and
 https://admin.stg.fedoraproject.org/pkgdb/packager/vondruch/requests

Thx, this is good start. You want be surprised if I'd like to modify the
request now ;)

BTW how to ask for new branch for example?


Vít
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBAgAGBQJU4yQOAAoJEAzgnueZF7h8OrIP/RaCFtkguIHSPgfB8JhgBW2s
3aZb/9UK+1PAMwDKip5YLOS1e/2PTGGdRuTdu4ZoBrZeMJqiKt/auzy3CDADn7rP
gKDPrqYTzwUMGsMtJPE3GczcDUyl5zKt6gLbEnGxn9kyUkP+U9OwwccnYiFXkY/6
7OpsKFtN9jT96VZgNA3V3NRNyb85ZHB3kEE5g0UhMFuhZWZf7RFZaS7iUag8kBc+
kHQoEu6r+x7euiLN3ASak+QW0EbzjKAroFAFhR3bBuYtTQuLXEQRP5TIZ7hWD3KC
Y/bbvvs6iUMTrBw8babGCGVUirI0qXC/5n3SBVdgZNzcFV42C80GA6PFcTX0ugkQ
IX/aZpY2D3WSzKWDB4XT3XOrAQ3g3iuuac/Q+ZiLBIkpWFsOvDI0DUVidYJ7e9C4
ChJjlleMDGFaiS9fhCZ8SyZimlbDC22EdHQL2m6nd+/KDkuo4SKmn5/JoR8z6BYv
Cyzhi6PWbeGTq8D4R/DhbxB7Lee0ugGd4+JBDXVYsmo4PRXBlo2oRjUz3cYLwm+7
oxrbYfduD9GnO3tk0j6LUNEKjdb2nEdEgKSO2HdSIy9HbZIhrl1n+qxtYgb2tC+R
KLGCaUC9bWkjRyJsuB3U+cVNipisdKeQVqDCdV68H/cCC/htSV7X4e1+65Gw9k7b
II3SyRQ1CXum7fKw+6J7
=7MJQ
-END PGP SIGNATURE-


___
infrastructure mailing list
infrastructure@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/infrastructure

Re: [release] pkgdb2 1.23.991

2015-02-17 Thread Vít Ondruch


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Dne 17.2.2015 v 11:44 Pierre-Yves Chibon napsal(a):
 - Per FESCo decision, Fedora branch requests will have by default a 7 days
   period during which packager with approveacls will be allowed to
grant/deny
   the request, this period does not apply if the requester has
approveacls on
   the package


What is actually the workflow for this?

https://admin.stg.fedoraproject.org/pkgdb/package/rubygem-abrt/requests/5

If I ask for a branch and I approve it myself, the branch will be
processed immediately? Or will I need to wait for 7 days? Shouldn't I as
a owner/POC/administrator of the package be allowed to ask for any
branch any time without any additional wait/action?

Actually now I found that I can't approve the action  That is weird.
That cannot be true.



Vít
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBAgAGBQJU4yXqAAoJEAzgnueZF7h8224P/3pZpPt7StbpvKZZ4Moa/Axd
e/fPo1OBpJnY5XFf3SCSpTqv1Z4ys4NGBrpxnOXREzvnTv8HWxZiLT1Qe9Jzz2CV
B2FlUXNupcIGbHayS0Ql7Qs/QnltzwZCVuc7KEwcWUnQpWYXLVCOml9leiHimMxa
YBbsLwGiT8KRUhB/ndKUWhIjs+ROoKt2bCFfjoM/NLuTibD2p4VH0sQQAzdDEgOm
9BS1RpBkpWzhuWiN5/aQie2va7s6Ztqcsse0GTTcRy8cleUTtss316ABrAGmHrZG
PIZ/z8wnCl3qR+Jg5g7joXfEMKGG87q/vz0lkdRYHkFlDdQdngwOOfhsh2hTbFl6
ODRXktJUKx9D2YzFYJ4jQEac+lVplws/8r3ZXI8f2ZVaeZVCNFjoWL5fK4Vvhmqy
LoYMkHO/EY/gEPmvuZvb1fhIXV7rhc+DeAu6NOjzczM/NZAvwZKGIYSy729Y+ctq
06y1BLkClIXkUJlHIxhK7tL0naIXYJgn/bDx5/c1LlPKg/p8mdxOKNIZrjntMH0M
uUDlhigvvEKUdVndP/UMRla0q6E0/I0i0TaEq84cuy6gRn1ctB5ZmwZ9Y8MIuM9d
Yk49nFvbXE8u58VjTHWsTPYATSPRYkSpsgFIRfLnTbkeOJLgrO6UZO1aSYLHGrIt
JMXZ52GhO3ib2aKcD8yE
=IVo3
-END PGP SIGNATURE-

___
infrastructure mailing list
infrastructure@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/infrastructure

Re: [release] elections 2.5.0

2015-02-16 Thread Vít Ondruch


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Dne 12.2.2015 v 18:14 Pierre-Yves Chibon napsal(a):

 And here is the result:
 https://admin.fedoraproject.org/voting/results/fesco-jan15
 (So most people vote on the first day or the last one ^^)

Hmmm, not exactly what I expected:


  504 Gateway Time-out

The server didn't respond in time.


Vít


-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBAgAGBQJU4hk+AAoJEAzgnueZF7h8CxMP/jOnK7S9JGQG1g8rFYwepqvG
chP91slHgM0p1PnUOQ/P/2WmbGkM6f6aFygJ0YzR7NuIYYx12lRaTR9BmeZXPWa1
oyIIW6ANh+gJxcI/TxCn8hagACgxCni2n4PakV6WdXQTEroOw1zVn16ToiZrWcF/
ZllZp0DzsAkFWbDDBf0meVqTlh6WF2GpdPPKMUvvBIhuNoISTTUldVBgZW92ZDw8
XpceB09+N84qhTdDZg0HxH2iEU1Y/JnLoZ3YzLGCS4CFcWexwI/KCyJGTq7pDrkj
rdWpSAnp3+cAg3qnt1FBTYRK1ujIAREMVGiAgvSbWxmRlTsSDS40m5AEChJykxxd
HtK/HvULW05wP54xZeoK8N0MgjhHwvv+6ABP2IPn1ycTOggmeSMzuEuIqajs67Dr
qo8sEABXYohCshcTyDSJljN4wslR1wtM0QHxpVZmbPApierrSJDA+3ylE6J3oX4w
82HCxB5Y2qsud4eSXh2lIO4h6aiwQvR8haRBLGStyJ1eGFqESm1q3gWis/Y6DQKR
KvuBO4OpwUVgG33Jja07NQKMplkANpNXo1BiyFdhC2tLjlFp9RwTvnIS+7aYf/FT
YA7kSbcIJWzIUATn9hOuLp0rxR8IwvPeTKf9cP+bOtvAGQRZgP9bJWzJi7Pzsv4T
R9DClbHEm/yepM1xze8M
=GYCW
-END PGP SIGNATURE-

___
infrastructure mailing list
infrastructure@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/infrastructure

Re: [release] pkgdb 1.23.99

2015-01-27 Thread Vít Ondruch

Dne 27.1.2015 v 08:37 Pierre-Yves Chibon napsal(a):
 On Tue, Jan 27, 2015 at 08:24:47AM +0100, Vít Ondruch wrote:
 Dne 26.1.2015 v 18:54 Pierre-Yves Chibon napsal(a):
 On Mon, Jan 26, 2015 at 06:14:36PM +0100, Vít Ondruch wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 Dne 26.1.2015 v 17:45 Pierre-Yves Chibon napsal(a):
 Dear all,

 I just pushed to stg a new version a pkgdb: 1.23.99 (pre-release of 1.24).

 This version is pretty big as it includes 6 months of work put in the
 process
 to request new package or new branch, thus taking theses processes out of
 bugzilla.

 The changelog is rather short though:
 * Mon Jan 26 2015 Pierre-Yves Chibon pin...@pingoured.fr - 1.23.99-1
 - Update to 1.23.99 (pre-release for 1.24)
 - New processes to request a new package or a new branch of a package
 directly
   in pkgdb instead of relying on bugzilla


 Please, have a look at it, test it, break it and let us know what is
 right/wrong
 with it: https://admin.stg.fedoraproject.org/pkgdb/
 And what is the status for new review? Don't think this belongs there.
 I still don't get the status ...
 It is the status of the package but you are right, it can probably be skipped
 when requesting a package and just left to 'Approved' (as anyway the request
 will not be approved if there is a problem).

 And what should be review URL?
 The button is meant to be used after the review has been completed in 
 bugzilla.
 I agree that the title on the button can be confusing. Any idea for a better
 wording?
 It is not obvious that the URL is supposed to be the BZ review ticket.
 It might help.
 I will adjust the UI

 And it finished with Internal server error when I clicked on the
 Create button :/
 Yeah there was some permission issue at the DB level which I had missed.
 Should be fixed now.
 Yes, I was able to request new package  probably ... since I don't
 know where it gone. I mean, there is list of Recent packages added
 (which does not sound english to me, but I'm not native speaker after
 all ;)), but where is the queue of new package requests?
 It's part of the admin interface but the API is public:
 https://admin.stg.fedoraproject.org/pkgdb/api/admin/actions
 So you requested a new package called: rubygem-binding_of_caller :)

I'd love to see at least packages I requested in some UI form. Otherwise
it might happen that the request will get duplicated, because they were
not processed soon enough or I forgot that I already did that, etc.


Vít

___
infrastructure mailing list
infrastructure@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/infrastructure

Re: [release] pkgdb 1.23.99

2015-01-26 Thread Vít Ondruch


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Dne 26.1.2015 v 17:45 Pierre-Yves Chibon napsal(a):
 Dear all,

 I just pushed to stg a new version a pkgdb: 1.23.99 (pre-release of 1.24).

 This version is pretty big as it includes 6 months of work put in the
process
 to request new package or new branch, thus taking theses processes out of
 bugzilla.

 The changelog is rather short though:
 * Mon Jan 26 2015 Pierre-Yves Chibon pin...@pingoured.fr - 1.23.99-1
 - Update to 1.23.99 (pre-release for 1.24)
 - New processes to request a new package or a new branch of a package
directly
   in pkgdb instead of relying on bugzilla


 Please, have a look at it, test it, break it and let us know what is
right/wrong
 with it: https://admin.stg.fedoraproject.org/pkgdb/

And what is the status for new review? Don't think this belongs there.

And what should be review URL?

And it finished with Internal server error when I clicked on the
Create button :/


Vít
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBAgAGBQJUxnX8AAoJEAzgnueZF7h8uNoP/Ajkuq5Dgb54CwRPHtDpPHYv
K6D8SnF9HJhYVZdZGexamvf8eH+o76cSFlhfy4xPljV6tcczVQzH5soNc9b6/q3S
gPheoT5B0MrXshJWCzw5aGk673nLr9uciqV8DbHTYGsrgMnV6MosWCLc6FcZvah+
/chN5mveCNc5YAl+TyUDimsGFjqnkjFc16mKDUipQ+PCRGBaEp6KpfBKZpJzuSZ3
IxrgWYMA4g/xVGPyxZ1a0O+p13p0jGDygT46CvQVxZ5tEE7LOi0F7i2tnoMyIaG5
/O/FACawVCzkbVLLmAuagzUnh20W7BfginozfmjDBBLbqf/ORxAePQbOaoLxZWJM
ah73pdAeix/skcz9bEIfLmnm5gSI5mQJM8HreHSnoXOpkcDECkZ7JLii25IRYD4u
fOXBVAMOT59T/OxGyvfdkTecknyYpjVKxYkb8IZ0fvtcL/EBXUqAwVeDRz/9nsTU
1actSRNw7inC50CSQnlzO60ffyjXiESpqS3URj+eea+K5tWZZrTSkgGXha4rOppp
OzcF84AGxCBLbg1SBKFLsF2azCW8VFexMA4q1VEk4g7toMF4b5BgcSfMZlGiG8RU
XH1CEf81V8wtyqWznW1nPtFLb8ybCVbYeEnv3sBc6PO1QnhJWKkLDBLe7egbzZCd
Q36W4tx0iEGazb0fsIYj
=cwrs
-END PGP SIGNATURE-


___
infrastructure mailing list
infrastructure@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/infrastructure

Re: [release] pkgdb 1.23.99

2015-01-26 Thread Vít Ondruch


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Dne 26.1.2015 v 17:45 Pierre-Yves Chibon napsal(a):
 Dear all,

 I just pushed to stg a new version a pkgdb: 1.23.99 (pre-release of 1.24).

 This version is pretty big as it includes 6 months of work put in the
process
 to request new package or new branch, thus taking theses processes out of
 bugzilla.

 The changelog is rather short though:
 * Mon Jan 26 2015 Pierre-Yves Chibon pin...@pingoured.fr - 1.23.99-1
 - Update to 1.23.99 (pre-release for 1.24)
 - New processes to request a new package or a new branch of a package
directly
   in pkgdb instead of relying on bugzilla


 Please, have a look at it, test it, break it and let us know what is
right/wrong
 with it: https://admin.stg.fedoraproject.org/pkgdb/

https://admin.stg.fedoraproject.org/pkgdb/package/qt5-qtlocation/


  Internal Server Error


Vít


-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBAgAGBQJUxnQTAAoJEAzgnueZF7h8L68P/2WVlYvyVsJjYI6Q3UH5DNJg
0W+M0UkR4FYm2O1XP59RCKe5jgkR1apZj5OWnjZeBlnrSEbgSYe2wHS6zYTXfmAY
Bghmr29CExhNwHDdi55ldoBBfa9fBo4zyojUWU+0TWdpqZKVHWD2tfLT7idttcWz
NusysZmP7Lss7dnCGFdjJLeo3Tf9XUz6hJOFK64hrxyacGUVLwwtYFhs6BleSDnW
cXX16w6hHLvbp+dvHFBNH3qHLva+2Bdraq0ISjwBf93djo5ScnpTQY8uN7ZjI2g5
pCXe7hPwTqqUkAiL+uhH4QDTNtLs5M8HjT1nop2A+ptngFRObmPkC0lAokFHmQ6q
VhaBeklpGsrhOGvzZWQr1rbSnPw1iJxuJUKq8IHL16fGxnuIG2mEZVar33WHvpyb
3tkxS+Ms3vSGsncmhitMvb3u45ZVqdF27HK5NDLZKe4Q+D3lE58BDHLKYThRd9JY
Ca/oAuAQfLR9JxSepH7ED4Ygsv6GPwv/yLcfFTe9jK8S8YNAZjb6LoM8vRBY+7rY
q7iS+pWEczWKT5o5kewfhAg44krHHaM8WbBHaHgFo7RLRCexFHQOO//dEshIjKfs
dXFCLtQ2XV2HPvtf0/mrSTyxBUkqArAORNgSNJrIxUq5lacHuxvWAp9kCh1r9GbY
kVbNjHSMwO1chYqLBclC
=0PKs
-END PGP SIGNATURE-

___
infrastructure mailing list
infrastructure@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/infrastructure

Re: [release] pkgdb 1.23.99

2015-01-26 Thread Vít Ondruch

Dne 26.1.2015 v 18:54 Pierre-Yves Chibon napsal(a):
 On Mon, Jan 26, 2015 at 06:14:36PM +0100, Vít Ondruch wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 Dne 26.1.2015 v 17:45 Pierre-Yves Chibon napsal(a):
 Dear all,

 I just pushed to stg a new version a pkgdb: 1.23.99 (pre-release of 1.24).

 This version is pretty big as it includes 6 months of work put in the
 process
 to request new package or new branch, thus taking theses processes out of
 bugzilla.

 The changelog is rather short though:
 * Mon Jan 26 2015 Pierre-Yves Chibon pin...@pingoured.fr - 1.23.99-1
 - Update to 1.23.99 (pre-release for 1.24)
 - New processes to request a new package or a new branch of a package
 directly
   in pkgdb instead of relying on bugzilla


 Please, have a look at it, test it, break it and let us know what is
 right/wrong
 with it: https://admin.stg.fedoraproject.org/pkgdb/
 And what is the status for new review? Don't think this belongs there.

I still don't get the status ...


 And what should be review URL?
 The button is meant to be used after the review has been completed in 
 bugzilla.
 I agree that the title on the button can be confusing. Any idea for a better
 wording?

It is not obvious that the URL is supposed to be the BZ review ticket.
It might help.


 And it finished with Internal server error when I clicked on the
 Create button :/
 Yeah there was some permission issue at the DB level which I had missed.
 Should be fixed now.

Yes, I was able to request new package  probably ... since I don't
know where it gone. I mean, there is list of Recent packages added
(which does not sound english to me, but I'm not native speaker after
all ;)), but where is the queue of new package requests?


Vít

___
infrastructure mailing list
infrastructure@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/infrastructure

Re: [release] pkgdb2 1.21

2014-12-12 Thread Vít Ondruch

Dne 11.12.2014 v 16:47 Pierre-Yves Chibon napsal(a):
 On Thu, Dec 11, 2014 at 04:24:39PM +0100, Vít Ondruch wrote:
 Dne 11.12.2014 v 13:44 Pierre-Yves Chibon napsal(a):
 On Fri, Nov 21, 2014 at 05:33:16PM +0100, Pierre-Yves Chibon wrote:
 - Add flag to set/update the monitoring flag on packages. This flag tells
   the-new-hotness whether the maintainers are interested in getting 
 bugzilla
   tickets about updates available on their package (updates being monitored
   via anitya: release-monitoring.org)
 Hmmm, this is probably not self explanatory enough. Looking at Ruby [1],
 is it enabled or not? I am afraid to click on the kye or the off button
 :) And how is the relation to the wiki page [2]. Since all rubygem-
 packages were monitored automatically up to now, what is their state.
 This is clearly not documented enough and I have probably been too quickly to
 push this update to prod (I wanted it out to get the improved API out).

 So looking at Ruby, it is currently off (I have to run the script to sync the
 packages from the wiki to pkgdb2).

 The idea is:
 - Having the upstream project on anitya
 - Having the upstream project mapped onto a Fedora package in anitya
 - Having the monitoring flag `on` on pkgdb
 - the-new-hotness will monitor for new releases announced by anitya
   - it will create a bugzilla ticket announcing the new release (so far we
 reproduce the behavior of cnucnu, the current upstream monitoring 
 solution)
   - it will download the sources and the spec file
   - it will adjust the spec file to bump version and fix release
   - it will do a scratch build using the new sources and adjusted spec
   - it will report on the bugzilla ticket if the scratch build was successful 
 or
 not.

 As the-new-hotness isn't running yet, changing the flag will not have any 
 effect
 yet.
 When we push the-new-hotness in production, we will retire cnucnu and adjust 
 the
 wiki page to provide more information on how these three systems work 
 together.

 I hope this answers your question and sorry for the confusion.

Wow, big plans! :)

So I won't rather touch the on/off until cnucnu is retired. Thanks for
explanation.


Vít
___
infrastructure mailing list
infrastructure@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/infrastructure

Re: [release] pkgdb2 1.21

2014-12-11 Thread Vít Ondruch

Dne 11.12.2014 v 13:44 Pierre-Yves Chibon napsal(a):
 On Fri, Nov 21, 2014 at 05:33:16PM +0100, Pierre-Yves Chibon wrote:
 - Add flag to set/update the monitoring flag on packages. This flag tells
   the-new-hotness whether the maintainers are interested in getting bugzilla
   tickets about updates available on their package (updates being monitored
   via anitya: release-monitoring.org)

Hmmm, this is probably not self explanatory enough. Looking at Ruby [1],
is it enabled or not? I am afraid to click on the kye or the off button
:) And how is the relation to the wiki page [2]. Since all rubygem-
packages were monitored automatically up to now, what is their state.


Vít



[1] https://admin.fedoraproject.org/pkgdb/package/ruby/
[2] https://fedoraproject.org/wiki/Upstream_release_monitoring

___
infrastructure mailing list
infrastructure@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/infrastructure

Re: ML spam

2014-03-12 Thread Vít Ondruch

Dne 11.3.2014 15:34, Kevin Fenzi napsal(a):
 On Tue, 11 Mar 2014 09:53:29 +0100
 Vít Ondruch vondr...@redhat.com wrote:

 Hi,

 As a moderator of ML I am wondering, why I should every day moderate
 the spam posts (although they never reach the ML). Is there some
 filter before the email enters a moderator queue? Could the
 sensitivity of filter be increased or something like that?

 There's not any filtering currently.

 I know it's a issue (I moderate a number of lists myself), but I've
 been trying to hold off implementing anything until we move to
 mailman3/hyperkitty. I don't want to put a lot of work into something
 now that we have to just redo once mailman3 is in place.

 Follow:
 https://fedorahosted.org/fedora-infrastructure/ticket/3863
 for progress on filtering in mailing lists.

 Happily, we are getting closer to that...

 kevin


I knew that this will be answer ;) and it is understandable. So looking
forward to mailman3.

Thanks anyway


Vít

___
infrastructure mailing list
infrastructure@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/infrastructure

ML spam

2014-03-11 Thread Vít Ondruch

Hi,

As a moderator of ML I am wondering, why I should every day moderate the
spam posts (although they never reach the ML). Is there some filter
before the email enters a moderator queue? Could the sensitivity of
filter be increased or something like that?


Vít
___
infrastructure mailing list
infrastructure@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/infrastructure

md5 vs sha256 in dist-git sources

2014-02-12 Thread Vít Ondruch

Dne 12.2.2014 12:15, Pierre-Yves Chibon napsal(a):
 On Wed, Feb 12, 2014 at 11:58:15AM +0100, Vít Ondruch wrote:
Dne 12.2.2014 09:46, Pierre-Yves Chibon napsal(a):
  So Ralph and I wrote summershum, it's a simple database storing for each 
 file in
  each package:
   - the packages name
   - the filename
   - the sha1sum of the file
   - the tarball name
   - the md5sum of the tarball

I don't think we should use md5sum. It is disabled by default in recent
OpenSSL if I am not mistaken.
 That's what we use in the lookaside cache (the source file in your git)

Interesting, since review guidelines [1] says this:

*MUST*: The sources used to build the package must match the upstream
source, as provided in the spec URL. Reviewers should use sha256sum for
this task as it is used by the |sources| file once imported into git.

But checking some of my packages, you are right that the sources file
has md5 has. May be somebody could look into this as well.


Vít



[1] http://fedoraproject.org/wiki/Packaging:ReviewGuidelines

___
infrastructure mailing list
infrastructure@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/infrastructure

Re: md5 vs sha256 in dist-git sources

2014-02-12 Thread Vít Ondruch

Dne 12.2.2014 15:29, Mathieu Bridon napsal(a):
 On Wed, 2014-02-12 at 13:44 +0100, Vít Ondruch wrote:
 Dne 12.2.2014 12:15, Pierre-Yves Chibon napsal(a):

 On Wed, Feb 12, 2014 at 11:58:15AM +0100, Vít Ondruch wrote:
Dne 12.2.2014 09:46, Pierre-Yves Chibon napsal(a):
  So Ralph and I wrote summershum, it's a simple database storing for each 
 file in
  each package:
   - the packages name
   - the filename
   - the sha1sum of the file
   - the tarball name
   - the md5sum of the tarball

I don't think we should use md5sum. It is disabled by default in recent
OpenSSL if I am not mistaken.
 That's what we use in the lookaside cache (the source file in your git)
 Interesting, since review guidelines [1] says this:

 MUST: The sources used to build the package must match the upstream
 source, as provided in the spec URL. Reviewers should use sha256sum
 for this task as it is used by the sources file once imported into
 git.

 But checking some of my packages, you are right that the sources
 file has md5 has. May be somebody could look into this as well.

 Afaik, the hashing mechanism to use is defined in the fedpkg
 configuration file:

 https://git.fedorahosted.org/cgit/fedpkg.git/tree/src/fedpkg.conf

 So theoretically, you could change it locally, and the sources you
 upload would then have their sha256sum in the `sources` file.

 But then, people who would download them with `fedpkg sources` (that
 includes Koji builders) would receive error messages that the checksum
 does not match.

 So we would probably need to add a fallback mechanism in pyrpkg, so that
 if sha256 verification fails, then it would try md5.



Looks to be sub-optimal so to say :)


Vít
___
infrastructure mailing list
infrastructure@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/infrastructure

Re: Announcing summershum

2014-02-12 Thread Vít Ondruch

Dne 12.2.2014 14:31, Pierre-Yves Chibon napsal(a):
 On Wed, Feb 12, 2014 at 01:47:08PM +0100, Vít Ondruch wrote:
 Dne 12.2.2014 12:44, Matthew Miller napsal(a):
 On Wed, Feb 12, 2014 at 09:46:27AM +0100, Pierre-Yves Chibon wrote:
 So Ralph and I wrote summershum, it's a simple database storing for each 
 file in
 each package:
  - the packages name
  - the filename
  - the sha1sum of the file
  - the tarball name
  - the md5sum of the tarball
  - a creation date
 Neat!

 So, I have one small suggestion and one possibly-too ambitious one. 

 The small one is that it might be nice to include the output of `file` on
 each file. 
 Technically doable but I'm curious, what use-case do you have in mind?

 Plus I've ran into:
 $ file /usr/share/doc/python-magic-5.04/example.py -b
 ASCII Java program text

 Seems legit, right? :)

 The `file` output would need to be store with `file` version, since its
 output is not stable in my experience.
 That's not a problem, we stored the tarball name which does contain the 
 version


I was referring to the file utility version. I know that file utility
provides different output for html file, sometimes they are clasified as
html, other time as xhtml or  xml. For Ruby files, it returns something
like ruby file or ruby module but the heuristic is unreliable.

See Matt's email, who parsed my objection correctly ;)



Vít
___
infrastructure mailing list
infrastructure@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/infrastructure

Re: Git-python patch for working with GPG signed commits

2013-12-06 Thread Vít Ondruch


Dne 4.12.2013 03:39, Ankur Sinha napsal(a):

Hi,

A few months ago, we noticed that the current git-python version did not
work with GPG signed commits[1]. Upstream's[2] been dead for almost 8
months now. There is however a pull request that adds support for GPG
signed commits[3].



There are also other issues with GitPython package [1]. Better would be 
to use some replacement if possible.



Vít



[1] https://bugzilla.redhat.com/show_bug.cgi?id=822055
___
infrastructure mailing list
infrastructure@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/infrastructure

ask.fp.o low ranking in Google

2013-10-18 Thread Vít Ondruch


Hi,

I am wondering why anytime I am searching some issue with Fedora, 
ask.fedoraproject.org is never shown in Google's results. How is that? 
That should be one of ours primary sources of answers for common questions.


For example, when I google for fedora 19 installation fails, on first 
page I get referecnes to


* fedora wiki
* fedoraforum.org
* wikihow
* bugzilla
* google groups
* and some other unknown pages

ask.fp.o does not appear on first 10 pages of Google. I am afraid it is 
useless service unless it appears in Google.


Any thoughts?

Thanks



Vít
___
infrastructure mailing list
infrastructure@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/infrastructure

Re: ask.fp.o low ranking in Google

2013-10-18 Thread Vít Ondruch


Dne 18.10.2013 10:48, g napsal(a):



On 10/18/2013 03:23 AM, Vít Ondruch wrote:



For example, when I google for fedora 19 installation fails, on first




ask.fp.o does not appear on first 10 pages of Google. I am afraid it is
useless service unless it appears in Google.

Any thoughts?


yes, do not use google, use;

   https://ixquick.com/eng/advanced-search.html

when i entered;

  with the exact phrase: fedora 19 installation fails

showed;

   About 1,410 results

1st screen of 1st page showed;

   https://ask.fedoraproject.org/

if you would like to see results, enter;


https://ixquick.com/do/search?q=%22fedora+19+installation+fails%22lui=english 



in your web browser url bar. watch for line wrap.


Thanks


welcome.



Heh :) Sorry for my ignorance, but this is first time I've heard about 
ixquick.com. Assuming I am not exception, I guess it should be more 
effective to do some SEO for Google instead of making aware the 
remaining 6bil people about ixquick.com



Vít
___
infrastructure mailing list
infrastructure@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/infrastructure

Re: ask.fp.o low ranking in Google

2013-10-18 Thread Vít Ondruch

Ok, that was completely artifical query, but for such generec question,
I would expect ask.fp.o to be on the first page and it is not. It is not
in first 10 pages. So user not only get any answer, but does not know
that there is place where he could ask at least.

But trying something less generic, such as
https://www.google.com/?#q=dualboot+fedora+win provides better results,
although I would expect ask.fp.o to be higher.

Vít

Dne 18.10.2013 15:13, Anshu Prateek napsal(a):

well,

Just because ask.fpo is fedora hosted , that doesn't mean its the
best source of content.

For this specific query, infact there are no questions on ask.fpo

https://ask.fedoraproject.org/questions/scope:all/sort:activity-desc/query:fedora%2019%20install%20fails/page:1/

SEO project aside, content is king.

As to it being useless, AFAIK, its just a fedora hosted app, not an
official documentation or answering place. fedora forums have been
around for years now, ask.fpo for months.

I would rather have a user directed to a valid answer than ask.fpo
with no results.

my 2 cents.

regards
Anshu Prateek

On Fri, Oct 18, 2013 at 1:53 PM, Vít Ondruch vondr...@redhat.com
mailto:vondr...@redhat.com wrote:

Hi,

I am wondering why anytime I am searching some issue with Fedora,
ask.fedoraproject.org http://ask.fedoraproject.org is never
shown in Google's results. How is that? That should be one of ours
primary sources of answers for common questions.

For example, when I google for fedora 19 installation fails, on
first page I get referecnes to

* fedora wiki
* fedoraforum.org http://fedoraforum.org
* wikihow
* bugzilla
* google groups
* and some other unknown pages

ask.fp.o does not appear on first 10 pages of Google. I am afraid
it is useless service unless it appears in Google.

Any thoughts?

Thanks

Vít
___
infrastructure mailing list
infrastructure@lists.fedoraproject.org
mailto:infrastructure@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/infrastructure

___
infrastructure mailing list
infrastructure@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/infrastructure

Re: areas where we can invest in automation?

2013-05-30 Thread Vít Ondruch


Dne 28.5.2013 20:08, Kevin Fenzi napsal(a):

Off the top of my head:


- Longer term/down the road, it would be nice if koji had cloud
   awareness. Instead of having a static pool of builders preallocated,
   if it could just talk to a openstack cloud or something and ask for a
   instance, wait for it, use it, terminate it.




I proposed this to Koji maintainers a while ago. Koji should share 
similar BE with Copr IMO, which does this already. But unfortunately, 
this idea was promptly dismissed, since sharing on Mock level is enough 
in their opinion :/



Vít
___
infrastructure mailing list
infrastructure@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/infrastructure

Re: Why Bodhi have not closed ticket when package was pushed to stable?

2013-05-22 Thread Vít Ondruch


Dne 21.5.2013 21:36, Luke Macken napsal(a):

On Tue, May 21, 2013 at 12:46:26PM +0200, Vít Ondruch wrote:

This [1] advisory was pushed into stable. Why Bodhi did not closed the
associated ticket in BZ [2]?

Thanks for pointing this out, Vít. I wrote some scripts[0] that were
supposed to clean up these stray bugs from the time we upgraded our
python-bugzilla package, but I only set the script to look from
2013-05-06 onwards. I'll modify the script and re-run it and try to
catch the remainder of these bugs.

Thanks,

luke

[0]: 
https://git.fedorahosted.org/cgit/bodhi.git/commit/?h=developid=2d5acd1715275451d7ea414f1fc182bb92f2c961
___



Thanks. My ticket is closed now.


Vít
___
infrastructure mailing list
infrastructure@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/infrastructure

Why Bodhi have not closed ticket when package was pushed to stable?

2013-05-21 Thread Vít Ondruch

This [1] advisory was pushed into stable. Why Bodhi did not closed the 
associated ticket in BZ [2]?



Thanks



Vít


[1] https://admin.fedoraproject.org/updates/FEDORA-2013-7282
[2] https://bugzilla.redhat.com/show_bug.cgi?id=947408
___
infrastructure mailing list
infrastructure@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/infrastructure

Re: FAS password on 3rd party pages?

2013-04-26 Thread Vít Ondruch


Dne 25.4.2013 20:31, Kevin Fenzi napsal(a):

On Thu, 25 Apr 2013 09:11:00 -0400
seth vidal skvi...@fedoraproject.org wrote:


Well I think the idea is simple enough - if there is one, branded and
obvious login page - and that page is openid then we're not training
our users to type their passwords into random websites.

Right. I think this is definitely where we are headed, but we aren't
there yet. ;(

So, yes, I think we need to add support to fedocal and blockerbugs for
openid, but not sure it's a blocker for them moving to production now.


Neither I am. I can justify both cases ;)

However, I would say, Fedocal is new application, not widely used yet, 
so why not to postpone the push to stable and do it right right from 
beginning?


blockerbugs? I dunno. The improvement to proposing the blocking bugs is 
well desired feature, but we are already past alpha and we survived 
without it up until now ... And the loging in is new feature if I am not 
mistaken, so why not do it better?




Moving forward, we might consider making it a blocker


Yes


, especially once
we have other things moved over to openid already, but I don't want to
change the goal posts for existing apps in the middle of the process.


I agree, it should not be retroactive.

Vít


___
infrastructure mailing list
infrastructure@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/infrastructure

Re: FAS password on 3rd party pages?

2013-04-25 Thread Vít Ondruch


Dne 25.4.2013 10:09, Pierre-Yves Chibon napsal(a):

On Thu, 2013-04-25 at 10:07 +0200, Vít Ondruch wrote:

Hi guys,

Since you want to push Fedocal and Blocker tracking into production,
would you mind to change you login forms, that I don't have to enter my
FAS password into your application dialog boxes? Although I understand
that they are Fedora's application, hosted on Fedora's infrastructure,
etc. , I don't feel comfortable to enter my FAS password into various
applications, which I consider 3rd party from this perspective.

Do you consider the wiki, pkgdb, bodhi as 3rd party apps?

Pierre


Well, you are right, they should be adjusted as well. Copr is doing it 
better.



Vít
___
infrastructure mailing list
infrastructure@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/infrastructure

Re: FAS password on 3rd party pages?

2013-04-25 Thread Vít Ondruch


Dne 25.4.2013 10:57, Pierre-Yves Chibon napsal(a):

On Thu, 2013-04-25 at 10:31 +0200, Vít Ondruch wrote:

Dne 25.4.2013 10:09, Pierre-Yves Chibon napsal(a):

On Thu, 2013-04-25 at 10:07 +0200, Vít Ondruch wrote:

Hi guys,

Since you want to push Fedocal and Blocker tracking into production,
would you mind to change you login forms, that I don't have to enter my
FAS password into your application dialog boxes? Although I understand
that they are Fedora's application, hosted on Fedora's infrastructure,
etc. , I don't feel comfortable to enter my FAS password into various
applications, which I consider 3rd party from this perspective.

Do you consider the wiki, pkgdb, bodhi as 3rd party apps?

Well, you are right, they should be adjusted as well. Copr is doing it
better.

So you are in fact speaking about porting our apps to use OpenID, which
is indeed something we are working on.


Thats good, thanks.


But, don't you consider OpenID as a 3rd party application as well ? :)


It is at least one single place to trust.

Vít
___
infrastructure mailing list
infrastructure@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/infrastructure

Re: Interested in Gitlab for Fedora Hosted Projects | GSoC 2013

2013-04-12 Thread Vít Ondruch


Hi Ankur,

Since GitLab is Ruby on Rails application and the first step is to 
package it and all its dependencies for Fedora, I recommend you to join 
the Ruby-SIG ML, where is already ongoing discussion about it.



Vít



Dne 11.4.2013 22:23, Ankur napsal(a):

Hey there,
I am Ankur Goel, currently pursuing Bachelors in Computer Science and 
Engineering at Indraprastha University, Delhi, India. I was going 
through /Gitlab as a front end for Fedora Hosted repositories/ 
project 
(http://fedoraproject.org/wiki/Summer_coding_ideas_for_2013#Setup_Gitlab_as_a_front_end_for_Fedora_Hosted_git_repositories) which 
is available on Ideas page of Fedora GSoC 2013. Mentor of this project 
is Dan Allen.
I am an active Rails developer and Ruby enthusiast. Very recently, I 
created and deployed an application http://bstorm.in/ for my 
university, which excellently ran and managed to get more than 16,600 
hits and 250,000 page views in a span of 6 days.


This project interested me a lot and if we managed to set it, as 
purposed, lot of developers can stick to this server instead of 
migrating to Github for their projects and collaboration.


I would like to get more inputs regarding what is expected from this 
project in depth. :)


Looking forward to an exciting and deployment-full summer!
Regards

--
-Ankur Goel
http://stackoverflow.com/users/1376448/kiddorails



___
infrastructure mailing list
infrastructure@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/infrastructure


___
infrastructure mailing list
infrastructure@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/infrastructure

82 matches

Mail list logo