Re: Fedora Notifications - howto?
On Thu, Aug 20, 2015 at 10:10:29AM -0600, Kevin Fenzi wrote: > On Thu, 20 Aug 2015 13:15:41 +0200 > Michael Schwendt wrote: > > I'm still in search of a howto. A howto about the user-interface, the > > various filters and rules, and real documentation about how to use it. > > I don't think there is such a howto, but we could look at creating one. There's some good description about how the system works and how to use it in this very thread (much of it from you, Michael, thanks for writing it!) I think a good place to record and organize it would be this document: https://infrastructure.fedoraproject.org/cgit/ansible.git/tree/roles/notifs/frontend/files/fedora-sitedocs/about.rst which gets rendered by the webapp here: https://apps.fedoraproject.org/notifications/about It currently reads more like notes-to-self from the developer [sic] and is a little dated (it pre-dates the ignore/include flag on individual rules) but it could be very useful if re-worked to be more user-focused, with stories like "if you wanted to set up things this way, do this... if you wanted to set up things that way, do that". signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Erroneous automated comments on some Review Request tickets
This morning we deployed a new release of 'the-new-hotness'[1], which is the service we run that monitors new upstream releases from release-monitoring.org, as well as koji builds, and uses this information to file and comment on bugzilla tickets. The release adds a new feature[2] that adds comments to Review Request bugs about successful scratch builds of that package. However, there was a bug. A kdevelop scratch build incorrectly triggered comments on 43 different review request tickets[3]. A patch has been added that should stop it from happening again[4]. My apologies for the spam. -Ralph Bean [1] - https://lists.fedoraproject.org/archives/list/infrastructure%40lists.fedoraproject.org/thread/5AGAHCBFUTGDIK7LQV6U6QHLZKQRG2WZ/ [2] - https://github.com/fedora-infra/the-new-hotness/pull/69 [3] - https://apps.fedoraproject.org/datagrepper/raw?category=hotness&start=1443010402&end=1443123402 [4] - https://github.com/fedora-infra/the-new-hotness/commit/606d666fbba63e5963f505b735425565be0f0d88 signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Removing packages that have broken dependencies in F23 tree
On Thu, Sep 24, 2015 at 04:34:11PM +0200, Kalev Lember wrote: > nodejs-grunt-contrib-copy ralph > nodejs-grunt-saucelabs ralph, piotrp > nodejs-proxy-agent ralph, piotrp These three got rebuilt this morning (made possible by piotrp's hard work on the rest of the dep chain). signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Call for testers for FMN
On Fri, Jul 18, 2014 at 09:33:01AM -0600, Orion Poplawski wrote:
> On 07/18/2014 05:47 AM, Pierre-Yves Chibon wrote:
> >On Fri, Jul 18, 2014 at 12:59:12PM +0200, Vít Ondruch wrote:
> >>Dne 17.7.2014 16:22, Pierre-Yves Chibon napsal(a):
> >>
> >>Why is the filter called filter? Isn't filter supposed to remove something?
> >>These filter seems to cause that email is sent, so that is probably not
> >>appropriate name IMO.
> >
> >I'm confused, filters should not be named filters?
> >FMN is based on fedmsg, which carries hundred of thousands of messages on a
> >daily basis and unless you explicitely ask, FMN won't be sending to your
> >inbox
> >every single one of them.
> >Sounds to me like filter is the appropriate word here.
>
> Filter generally implies removing things.
>
> Perhaps "subscription" would be better here?
Agreed. In early development, they were called 'chains' (as in 'a
chain of rules'), but it was decided that that made even less sense.
In future releases I hope to add toggle switches to the things that
are now called 'filters' so that they can be made positive or
negative and conjunctive or disjunctive ('all' versus 'any').
pgpE8sS_x1ImX.pgp
Description: PGP signature
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Call for testers for FMN
On Thu, Jul 17, 2014 at 04:22:59PM +0200, Pierre-Yves Chibon wrote: > So please, register on FMN: > https://apps.fedoraproject.org/notifications/ > > Test it and open bug tickets and RFEs here: > https://github.com/fedora-infra/fmn/issues As a result of surge of new users, FMN is performing poorly under high load. I'm currently working to relieve this and hope to have it back to snappy performance next week. Please do continue to file bugs as you encounter them. pgpDeX5owg9MK.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Call for testers for FMN
On Fri, Jul 18, 2014 at 12:04:48PM -0400, Ralph Bean wrote: > On Thu, Jul 17, 2014 at 04:22:59PM +0200, Pierre-Yves Chibon wrote: > > So please, register on FMN: > > https://apps.fedoraproject.org/notifications/ > > > > Test it and open bug tickets and RFEs here: > > https://github.com/fedora-infra/fmn/issues > > As a result of surge of new users, FMN is performing poorly under high > load. I'm currently working to relieve this and hope to have it back > to snappy performance next week. It took longer than a week, but a new release of the FMN backend is in place now and it appears to be performing well. > Please do continue to file bugs as you encounter them. pgpCkge_C6b45.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
FMN Announcement: Plans for a (near) future
Dear all, We would like to invite you to take a closer look at the Fedora Notification service: https://apps.fedoraproject.org/notifications/ This service will allow you to customize the notifications you receive, you may ask it to send you IRC notification for successfull koji builds and email notifications for failed koji builds. You may ask it to send you pkgdb notifications only via IRC and even to wait a little after receiving the first pkgdb notification before sending it to you (thus allowing it to batch your notifications into a digest). We have already mentioned this service in an email on the devel list few months ago[1] and we now are getting to that point that we want to turn off email notifications from pkgdb. Bodhi2 which is planned in the coming months will also not have email notifications. All information will be going through fedmsg and you will be able to receive them (or not) via FMN. This is thus a head-up about what will happen in a very near future. As a packager, it is important that you are notified about a number of actions happening on the packages you maintain. We looked at who is currently using FMN vs who is in the packager group: 1566 packagers 160 users in FMN 1453 packagers do not have a FMN account Here's what we're going to be doing (soon): - All the packagers that do not have a FMN account (ie: never logged in) will have an account created automatically with the default rules that everyone has when they log in for the first time (these rules should provide the same level of notification as one currently has with the different systems). - We have code in place that will automatically create a FMN account for users added to the packager group that do not already have an account there. So please, have a look at it or if you are a packager, we will create you an account automatically in the next few weeks. Finally, if you have any comments or questions, feel free to open a ticket at: https://github.com/fedora-infra/fmn/ Thanks for your attention, - Ralph on behalf of the Fedora Infrastructure team [1] https://lists.fedoraproject.org/pipermail/devel/2014-July/201118.html pgpcJKv0aCoBf.pgp Description: PGP signature ___ devel-announce mailing list devel-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel-announce-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Flock 2014 attendee badge
On Thu, Sep 18, 2014 at 09:44:01AM +1000, Anibal Monsalve Salazar wrote: > https://badges.fedoraproject.org/badge/flock-2014-attendee > > I would like to know how to add the Flock 2014 attendee badge to my list of > badges. Is this something I could do myself? > > Leonardo Menezes Vaz and Toshio Kuratomi (amongst others) know I was there. > :-) > > I've done google searches and searched the wiki and couldn't find anything > about this. Hi! There was a QR-code on the back of the Flock 2014 pamphlet that was handed out to attendees at the event. Scanning it would award the badge to your account. If someone can vouch for Anibal, someone from sysadmin-badges can award the badge manually ex post facto. FYI, for future badge-related questions there is a dedicated mailing list: https://lists.fedoraproject.org/mailman/listinfo/badges pgpQqsckhkldQ.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Bumping python-requests in f20?
There have been some people asking if we can update python-requests in f20 from 1.2.3 to 2.3.0. I'll create an update for it in a few days unless there are any objections. pgpTysJSbVd8l.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Bumping python-requests in f20?
On Thu, Oct 23, 2014 at 01:16:29PM -0700, Ed Marshall wrote: > Is it API-compatible? Not exactly https://github.com/kennethreitz/requests/blob/master/HISTORY.rst#230-2014-05-16 pgpwJFv1un9XY.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Bumping python-requests in f20?
On Fri, Oct 24, 2014 at 01:15:14PM +0200, Kalev Lember wrote: > On 10/23/2014 10:57 PM, Ralph Bean wrote: > > On Thu, Oct 23, 2014 at 01:16:29PM -0700, Ed Marshall wrote: > >> Is it API-compatible? > > > > Not exactly > > https://github.com/kennethreitz/requests/blob/master/HISTORY.rst#230-2014-05-16 > > I would personally say no to updating libraries to incompatible > versions. We already have way too much churn in F20; doing the update > would mean updating and retesting anything that uses python-requests. > And not just testing the packages in Fedora, this could also potentially > break 3rd party programs that people might have written in house. > > Maybe just tell the users who were asking for an update to switch to > F21? It's really close now and I know several people who are using it > daily on their main workstations and are very happy with it. I'm convinced and will let it sit as is. Thanks for writing back. pgpwgAs221ip9.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: koji rawhide broken: ImportError: cannot import name ProtocolError
On Wed, Nov 05, 2014 at 11:44:18AM -0700, Orion Poplawski wrote: > On 11/05/2014 11:35 AM, Richard W.M. Jones wrote: > > > > https://kojipkgs.fedoraproject.org//work/tasks/7943/8047943/mock_output.log > > > > Something is broken. fedpkg maybe? > > > > Rich. > > > > missing/incompatible dep for python-requests? It was just updated to > python-requests-2.4.3-1.fc22 Yes, lpython-requests was the problem (it needs a newer python-urllib3). It is untagged from f22 for now while I get python-urllib3 in. Sorry for the mess. pgpWCTxgEw5zN.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: New Upstream Release Monitoring Systems
On Sun, Mar 01, 2015 at 01:58:24PM +0100, Michael Schwendt wrote: > On Fri, 20 Feb 2015 15:36:11 -0500, Ralph Bean wrote: > > > If you encounter bugs or have requests for enhancement, as always please do > > file them[6][7][8].. > > Done. Thanks for a premature April Fool's prank. ;) Heh, no problem. ;) For those not in the know, this is in reference to: https://github.com/fedora-infra/the-new-hotness/issues/29 signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
More packager notifications migrated to FMN
Recall that the infrastructure team has been working on a new notifications system[1] in an attempt to unify some of the notifications that get pushed out by our infrastructure. As the new system improves (and as we get time to clean house), we will be turning off the native notifications of various systems. - Back in February, the native emails from Koji were turned off[2]. - This past week, we turned off the old and well-loved emails from pkgdb[3] and dist-git[4]. For your personal notifications, the default settings in FMN[5] should get you what you need. There are some mailing lists that had been archiving direct notifications from from pkgdb and dist-git and we've been working to add those into the new system. The scm-commits[6] and perl-devel[7] lists are working as expected now. The meetingminutes list[8] now also automatically receives meeting minutes from FMN, so, no need to go and send your minutes there if you have chaired an irc meeting. If you own a mailing list that has mysteriously stopped receiving automated emails, please file an issue[9] requesting that we set up forwarding for you. ** P.S., unrelated, but zodbot grew a new feature recently: the "#help" command is available in IRC meetings to let you solicit help from the broader community on.. anything. Use it liberally. We'll be building a "calls for help" web UI around it in the coming year. [1] - https://lists.fedoraproject.org/pipermail/devel-announce/2014-September/001434.html [2] - https://lists.fedoraproject.org/pipermail/devel-announce/2015-February/001540.html [3] - https://admin.fedoraproject.org/pkgdb [4] - http://pkgs.fedoraproject.org/cgit/ [5] - https://apps.fedoraproject.org/notifications [6] - https://lists.fedoraproject.org/pipermail/scm-commits/ [7] - https://lists.fedoraproject.org/pipermail/perl-devel/ [8] - https://lists.fedoraproject.org/pipermail/meetingminutes/ [9] - https://github.com/fedora-infra/fmn/issues/new signature.asc Description: PGP signature ___ devel-announce mailing list devel-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel-announce-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Seeking bold, intrepid package reviewers
The Messaging SIG has been working on building a messaging bus for Fedora Infrastructure and the main obstacle to testing stuff in our staging environment is a boatload of package reviews. If anyone is up to help, it would be much appreciated. I'm willing to swap reviews as well if you need a reviewer for yours. https://bugzilla.redhat.com/show_bug.cgi?id=811732 https://bugzilla.redhat.com/show_bug.cgi?id=811769 https://bugzilla.redhat.com/show_bug.cgi?id=811782 https://bugzilla.redhat.com/show_bug.cgi?id=812030 https://bugzilla.redhat.com/show_bug.cgi?id=811739 https://bugzilla.redhat.com/show_bug.cgi?id=811750 https://bugzilla.redhat.com/show_bug.cgi?id=812059 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Seeking bold, intrepid package reviewers
On Thu, May 03, 2012 at 10:33:20AM -0400, Neil Horman wrote: > Just FYI, you probably want to set the fedora-review flag to '?' on those so > they're more visible to potential reviewers Done. Thank you. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Seeking bold, intrepid package reviewers
On Thu, May 03, 2012 at 10:39:27AM -0400, Neil Horman wrote: > On Thu, May 03, 2012 at 09:37:04AM -0500, Jon Ciesla wrote: > > On Thu, May 3, 2012 at 9:33 AM, Neil Horman wrote: > > > Just FYI, you probably want to set the fedora-review flag to '?' on those > > > so > > > they're more visible to potential reviewers > > > Neil > > > > No, you don't, that's set by the reviewer when the start the review, > > then "+" at approval. > > > Yup, my bad. Okay. I just un-set the flag again. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Seeking bold, intrepid package reviewers
On Thu, May 03, 2012 at 09:03:54AM -0600, Jerry James wrote: > On Thu, May 3, 2012 at 7:27 AM, Ralph Bean wrote: > > If anyone is up to help, it would be much appreciated. I'm willing to > > swap reviews as well if you need a reviewer for yours. > > I offered a review swap a couple of days ago that nobody has taken me > up on. Can you review these in exchange for me reviewing a couple of > yours? Sure thing! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Scheduling new meeting time for Messaging SIG
The Messaging SIG has been meeting on Tuesdays at 16.00 UTC. Turnout has been a little low and we concluded that it's not the best time. If you're interested in participating in meetings, please fill out the following survey so I can get a good idea of when to place them: http://whenisgood.net/fedmsg For the curious, here's a list of the archived meeting logs: https://github.com/ralphbean/fedmsg/blob/develop/doc/meetings.rst -threebean -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: To someone with power to push packages on Fedora 21
On Fri, Oct 16, 2015 at 09:00:29AM -0600, Kevin Fenzi wrote: > I'd suggest all maintainers should periodically check: > https://bodhi.fedoraproject.org/updates/?user=&status=testing > For their updates that are in testing. Noting here that there's an easy link to that url from your Bodhi profile page at https://bodhi.fedoraproject.org/users/, where it says "Testing >". signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: fedora-packages out of sync with bugzilla
On Tue, Oct 20, 2015 at 10:41:45AM -0600, Kevin Fenzi wrote: > We are planning a re-work/re-write of the application entirely, but > it's not happened yet. ;( Small correction, we started on it at the end of last week! https://github.com/fedora-infra/fedora-packages/pulse/weekly We'll put out a small bugfix release soon with some simple changes (mostly to make sure that we have the release/deployment cycle down-pat) and then we'll get into some of the more structural changes in the coming weeks. signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [RFC] DistGit Container Image namespacing for Layered Image Build Service
On Thu, Nov 12, 2015 at 03:01:49PM -0500, Ray Strode wrote: > Hi, > > On Tue, Nov 10, 2015 at 1:08 PM, Adam Miller > wrote: > > If we were to go with the former rather than the latter, we would need > > to find a way to "namespace" container images so they can be > > determined as different. I've thought about this a lot and I worry > > about defining a namespace by some alphanumberic sequence because I > > just know that at some point there will end up being a piece of > > software in the ecosystem that we want to package as a rpm that will > > share this pattern and result in problematic filtering. We could > > accept that risk and simply say "this sequence is a reserved word" or > > use a special character as the leading character in a DistGit > > repository name to signify that it is a container. > > git repositories normally use '/' to separate namespaces, so i'd propose > > $ fedpkg clone containers/cockpit > > and maybe add support for > > $ fedpkg clone srpms/cockpit > > at the same time. > > This has the added benefit that cgit will automatically filter docker > reposistories when you visit, e.g, > > http://pkgs.fedoraproject.org/cgit/containers/ I like this too. Here are three thoughts: Perhaps, we use 'dockerfiles' for the prefix instead of 'containers', because presumably there will be some whole new way to build containers in 2017, and we'll need to keep our dockerfiles/ repos separate from our awesomefiles/ repos. We could also use this opportunity to move the kickstarts (another input to koji builds) away from https://fedorahosted.org/spin-kickstarts and over to dist-git as well, with a namespace like 'kickstarts/kde' and 'kickstarts/lxde'. The existing rpm content could be moved to a 'specfiles/' namespace (or maybe 'srpms/'?) but we could further add some apache httpd rules that respond with a redirect to the 'srpms/' namespace if the requests to the base namespaceless-namespace level are met with a 404. -- "when in doubt, default to srpms/". That might help keep some of our existing tools working as-is without too much catastrophe. signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Outage: Pkgdb2 and dist-git upgrade (namespacing) 2015-12-17 15:00 UTC
Outage: Pkgdb2 and dist-git upgrade (namespacing) 2015-12-17 15:00 UTC There will be an outage starting at 2015-12-17 15:00 UTC, which will last approximately 1.5 hours. To convert UTC to your local time, take a look at https://fedoraproject.org/wiki/UTCHowto or run: date -d '2015-12-17 15:00 UTC' Reason for outage: Upgrade pkgdb2 and adjust dist-git for namespacing packages. Affected Services: Bodhi https://admin.fedoraproject.org/updates/ PkgDB2 https://admin.fedoraproject.org/pkgdb/ dist-githttps://pkgs.fedoraproject.org/cgit/ 'fedpkg' Services not listed are not affected by this outage. Contact Information: #fedora-admin on freenode. Ticket Link: https://fedorahosted.org/fedora-infrastructure/ticket/5033 Please join #fedora-admin in irc.freenode.net or add comments to the ticket for this outage above. signature.asc Description: PGP signature ___ devel-announce mailing list devel-annou...@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel-annou...@lists.fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: How do you unsubscribe from mdapi meta-data update?
On Wed, Dec 16, 2015 at 11:44:54AM -0700, Kevin Fenzi wrote: > On Wed, 16 Dec 2015 10:19:50 -0500 > Steve Grubb wrote: > > > Hello, > > > > Something started sending me emails about $SUBJECT. The email says > > this is due to my preferences and give an URL. Clicking on that URL > > leads to a page that says, "Transaction expired, or cookies not > > available. Try to login again." > > > > Logging in again leads to no useful page. It simply says "You will be > > redirected to this application whenever another application requires > > you to authenticate." > > > > Reclicking the original link still says I'm not logged in. Logging > > into my FAS account does not allow me to pick any preference about > > this email. How does one stop it? Why is the URL that the email gives > > wrong? > > Can you share the url it's giving you? > > It should be something like: > > https://apps.fedoraproject.org/notifications/.id.fedoraproject.org/ > > Which should redirect you to the Fedora ipsilon auth server. > It sounds like it is redirecting you, but somehow it thinks you have > taken too long to login and says the transaction is expired? > > In any case you can go to: > > https://apps.fedoraproject.org/notifications/ > > click the 'login button' and login. > Then you should be able to add a filter to drop those notifications. > > kevin FYI, when we rolled out mdapi, we ran a script written to exclude mdapi messages from everyone's notification preferences. https://github.com/fedora-infra/fmn.lib/pull/55 Steve, if you're still having issue with it you can mail me directly or ask in #fedora-apps on freenode and we can get your account sorted out. signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Fw: the-new-hotness saw an update for eiciel, but pkgdb says the maintainers are not interested in bugs being filed
On Fri, Jan 15, 2016 at 06:00:48PM +0100, Michael Schwendt wrote: > Anyone knows what this cryptic message is trying to tell? > What kind of "update" does it refer to? > Is this a belated notification about 0.9.11 which is in koji > since Dec 2015 already? > > [...] > > Begin forwarded message: > > Subject: the-new-hotness saw an update for eiciel, but pkgdb says the > maintainers are not interested in bugs being filed > > > the-new-hotness saw an update for eiciel, but pkgdb says the maintainers are > not interested in bugs being filed > https://release-monitoring.org/project/8847/ Yeah, looking at the message history for eicil helps show what happened: https://apps.fedoraproject.org/datagrepper/raw?package=eiciel It looks like someone added eicil to release-monitoring.org, which triggered a check. But, like the message says, the pkgdb flag for filing bugs new upstream release bugs in bugzilla is turned off for eicil, so it didn't get any further than that. Some vocabulary: - release-monitoring.org - the code for this is called 'anitya' https://github.com/fedora-infra/anitya it monitors upstream projects for new tarball releases and publishes messages to a message bus when it finds them. It is intended to be distro-agnostic.. so you'll find stuff other than Fedora stuff there. - the-new-hotness https://github.com/fedora-infra/the-new-hotness This is a Fedora-specific service running in the background in our infrastructure. It listens for messages from anitya, and in response it files bugs in bugzilla for package maintainers, letting them know that a new upstream release is available. You can toggle its behavior by turning some per-package flags on and off in pkgdb. Does that help? signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: the-new-hotness saw an update for eiciel, but pkgdb says the maintainers are not interested in bugs being filed
On Fri, Jan 15, 2016 at 06:37:25PM +0100, Michael Schwendt wrote: > On Fri, 15 Jan 2016 12:19:07 -0500, Ralph Bean wrote: > > > > https://release-monitoring.org/project/8847/ > > > > Yeah, looking at the message history for eicil helps show what > > happened: > > > > https://apps.fedoraproject.org/datagrepper/raw?package=eiciel > > > > It looks like someone added eicil to release-monitoring.org, which > > triggered a check. > > And the check didn't notice that there is no new upstream release? > > > Does that help? > > A bit. I'm aware of the release monitoring services, and it's ON for > some of my packages. But this particular message is confusing, since there > is no new upstream release. Last one is from Sep 2015. And notifying about > an update that is no update doesn't make sense. Yeah, could you file a bug on https://github.com/fedora-infra/the-new-hotness about this, when you ahve time, please? From a quick look at the code, it looks like you will receive a notification like this if pkgdb monitoring is set to False.. but you will receive *no* notification in this scenario if monitoring is set to True (kind of the opposite of what you'd expect). https://github.com/fedora-infra/the-new-hotness/blob/develop/hotness/consumers.py#L195-L262 signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Package Review Swap Request: datanommer
Hello, Anyone interested in swapping package reviews? https://bugzilla.redhat.com/show_bug.cgi?id=853252 Thanks in advance- -Ralph -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Release of fedora-review 0.3.0 done, 0.3.1 hotfix on the way
On Tue, Sep 25, 2012 at 04:37:31PM +0200, Stanislav Ochotnicky wrote: > fedora-review development team proudly presents :-) > > Release of fedora-review 0.3.0 [1-3] Exciting! Thanks for working on this! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Orphaning many packages
On Mon, Nov 26, 2012 at 04:08:22PM -0800, Jesse Keating wrote: > python-offtrac I'll take this one! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: New Online search for the Fedora Source
On Fri, Nov 30, 2012 at 01:38:29PM +, Pádraig Brady wrote: > On 11/30/2012 12:09 PM, Pádraig Brady wrote: > >Benjamin Boyter has recently indexed the entire Fedora Source code. > >I.E. all 2 billion lines, 11K packages, 132 GB of it. > > > >For details including search syntax, please see: > > http://www.pixelbeat.org/docs/fedora_source.html This is really nice. Thanks for sharing! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Solicitation: Review Swap
Anyone interested in a package review swap? python-logutils: https://bugzilla.redhat.com/show_bug.cgi?id=884041 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: bugz.fedoraproject.org/ MIA?
On Thu, Dec 06, 2012 at 10:01:32PM +0200, Ville Skyttä wrote: > Hello, > > http://bugz.fedoraproject.org/ URLs no longer work, they > redirect to https://apps.fedoraproject.org/packages/error which appears > to be some kind of a 404 Not Found page. Known issue? Sorry for the troubles. I switched the bugz alias over from pkgdb to the newer fedora-packages webapp last Friday as per https://fedorahosted.org/fedoracommunity/ticket/381 What package in particular are you trying? For instance, https://bugz.fedoraproject.org/nethack works for me. An idea: packages that have do not have rawhide builds are not indexed by the fedora-packages webapp. This could be why your request is returning a 404. -Ralph pgpdMO0xhpyoV.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: bugz.fedoraproject.org/ MIA?
On Thu, Dec 06, 2012 at 11:54:07PM -0800, Adam Williamson wrote: > On Fri, 2012-12-07 at 08:42 +0800, Christopher Meng wrote: > > In fact in some area it takes me 1 min to finish loading the > > page.. > > Bugzilla has been veeery slow for the last week or two. Painfully slow. > Incredibly efficiency-destroying slow, if you're oh say a full-time QA > person and so spend several hours a day loading bug URLs. Grr... In one of the updates to RH BZ over the last few months, we lost the ability to do multicall queries with the python-bugzilla module. This is partly to blame; we can do a lot to speed it up in time. pgpHkQ2tqFCxW.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: bugz.fedoraproject.org trouble
On Fri, Dec 07, 2012 at 04:57:00PM +0100, Michael Schwendt wrote: > There used to be > > http://bugz.fedoraproject.org/SOURCE-RPM-NAME > e.g. > http://bugz.fedoraproject.org/gnome-packagekit > > Whoever has installed the new non-working software on that server, > could it be replaced with the previous version again, please? > > The pages don't want to load successfully anymore: > >Error loading the data for this page element >... >Error loading the data for this page element > > And >This package has no bugs - go file some!!! > is displayed always, apparently. > > This is very unfortunate and sad, especially during the Fedora Beta phase. > A very convenient way to take a look at existing bug reports is gone. > A very convenient way to follow a quick link into Fedora bugzilla is gone. > > And what is this thing called anyway? > There are a couple of links at the bottom of the page, which don't work > -> http://fedoracommunity.fedorahosted.org/ > -> http://moksha.fedorahosted.org/ > seems to be related to the "fedora community project", but only > the src.rpm/rpm repo links work, which contain many rpms. I introduced the switch-over as per this ticket https://fedorahosted.org/fedoracommunity/ticket/381 The site (called fedora-packages, the successor to fedoracommunity) has been up for almost a year and we were mistaken in thinking enough developers had used it that the kinks had been worked out. You're quite right about this being poor timing. I just reverted the alias, so bugz.fedoraproject.org/package-name should work again (using the pkgdb site). We'll hammer on the fedora-packages app some more during freeze to try and get it up-to-snuff. For the curious, part of the motivation for making a change at all is that the pkgdb app has undergone feature creep over time. Its codebase is older and needs a port/rewrite to a more modern framework. We're hoping to trim some of it's features which already exist in other apps (like this bugs reporting feature), scale it down, and rewrite the core as a more maintainable unit.. the core being acl controls. -Ralph pgpL4WqgNBQsp.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
fedmsg for voting?
A question has come up in #fedora-apps as to whether or not we should publish fedmsg messages for voting. In particular, we're looking now at the new "nuancier" webapp[0] that will be used to vote on supplemental wallpapers. It is in development. There is a demo instance[1]. There is a pull request up[2] that adds fedmsg messages to nuancier. It publishes messages when an election admin opens or closes an election for voting, as well as when an election admin publishes or rescinds the results of an election. Everyone seems to think that this is fine. What is under question is that it publishes a message for each set of votes cast by users[3]. It includes the number of votes cast, the fas username of the person who did the voting, and in what election they voted. It does *not* include what the person voted for or against. If we are able to add fedmsg messages to this, then we will be able to award badges for voting on wallpapers. That would be nice. Whatever the decision we come to on the supplemental wallpaper voting app, we would like to apply that same logic fedmsg messages on the general elections voting app later down the road. [0] - https://github.com/fedora-infra/nuancier-lite [1] - http://209.132.184.207/nuancier/ [2] - https://github.com/fedora-infra/nuancier-lite/pull/2 [3] - https://github.com/fedora-infra/nuancier-lite/commit/66cde916e9eddfa3ddbb966ef8fb8f5bdd97c9c6 pgpao7ps8DLDr.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: fedmsg for voting?
On Tue, Sep 10, 2013 at 02:46:17PM -0600, Stephen John Smoogen wrote:
> On 10 September 2013 14:24, inode0 wrote:
> > On Tue, Sep 10, 2013 at 3:08 PM, Ralph Bean wrote:
> > > If we are able to add fedmsg messages to this, then we will be able to
> > > award badges for voting on wallpapers. That would be nice.
> >
> > Maybe it is just me but I really don't want badges for voting. I don't
> > wear those stickers they give you at the voting places in the US and I
> > don't want you sticking one on my back as I walk out of the Fedora
> > voting booth either.
> >
> I guess we need to make sure that we have a "I don't want this sticker"
> button in the booth mode. Because personally I want a sticker for voting...
> but I don't want to make you have one.
FWIW, if you log in to https://badges.fedoraproject.org/ and visit
your profile, you can opt out of all badge-stuff in one click
("Deactivate Account").
pgpkJhFq6MdN1.pgp
Description: PGP signature
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: fedmsg for voting?
On Tue, Sep 10, 2013 at 05:57:45PM -0400, DJ Delorie wrote:
> > > > you can opt out of all badge-stuff in one click ("Deactivate
> > > > Account").
> > >=20
> > > Does this deactivate your FAS account, or just the badges?
> >
> > Just the badges. You won't show up on the badges.fp.o frontpage, or the
> > badges.fp.o leaderboard, and the backend awarder won't consider you
> > for future badges. "Deactivating your account" there has no effect beyond
> > the badges systems.
>
> Thanks! I'm out.
Cool, good. :)
> Why wasn't it opt-in in the first place? We expect that of mailing lists...
We talked about it, but opt-out won at FUDCon Lawrence. FWIW, its
different from mailing lists in that no information is being
distributed *to* you. Its just a meta-layer on top of the already
public git logs, koji logs, etc..
pgpUyJ0CtCXA5.pgp
Description: PGP signature
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: fedmsg for voting?
On Tue, Sep 10, 2013 at 05:00:11PM -0500, inode0 wrote: > On Tue, Sep 10, 2013 at 4:50 PM, Ralph Bean wrote: > > On Tue, Sep 10, 2013 at 05:06:58PM -0400, DJ Delorie wrote: > >> Does this deactivate your FAS account, or just the badges? > > > > Just the badges. You won't show up on the badges.fp.o frontpage, or the > > badges.fp.o leaderboard, and the backend awarder won't consider you > > for future badges. "Deactivating your account" there has no effect beyond > > the badges systems. > > Would it prevent messages about my voting behavior from being visible > in other places? No, it would not. "Just the badges." pgpgaiuA_06sh.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: fedmsg for voting?
On Tue, Sep 10, 2013 at 05:06:58PM -0400, DJ Delorie wrote:
>
> > FWIW, if you log in to https://badges.fedoraproject.org/ and visit
> > your profile,
>
> I got "Internal Server Error" when I tried this... and now I'm on the
> home page, when what I really wanted was to make sure I had nothing to
> do with it :-P
Oh no! Sorry about that. I just tried it too but I couldn't
duplicate the error.
> > you can opt out of all badge-stuff in one click ("Deactivate
> > Account").
>
> Does this deactivate your FAS account, or just the badges?
Just the badges. You won't show up on the badges.fp.o frontpage, or the
badges.fp.o leaderboard, and the backend awarder won't consider you
for future badges. "Deactivating your account" there has no effect beyond
the badges systems.
pgp63UmwCE3Ky.pgp
Description: PGP signature
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: fedmsg for voting?
On Wed, Sep 11, 2013 at 09:23:44PM -0700, Toshio Kuratomi wrote: > On Sep 11, 2013 6:02 PM, "Matthew Miller" wrote: > > What if we made this like the "I voted" stickers -- you can get one by > > checking a box in the voting app? (Even if, by the way, you cast no actual > > votes?) > > > I had thought that this would trigger off of someone hitting submit on the > election page. That should vote 0 for all candidates if no votes are > assigned but still meet the trigger condition. Not sure if that meets the > criteria for objectors, though. Ralph bean should weigh in here as to > whether "logged in during an election period" would also be suitable (which > was something that people seemed to think would be acceptable earlier in > the thread). Hm, its not worth doing if we're going to make it complex like this. I think we should just drop it. No fedmsg broadcast for votes, only for election period opening/closing and only for election results publication/retraction by the admin (with obviously no user participation data included). It is just not important enough to: 1) cause anyone any worry. 2) bother engineering a complicated "compromise" solution. If someone wants to argue that we still try to make it happen, I'll hear that and implement it if a consensus is formed. (FWIW, personally I'm still all for it). pgpwTp59vTV_M.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
A fresh idea (was: fedmsg for voting?)
On Thu, Sep 12, 2013 at 05:30:43PM +0200, Pierre-Yves Chibon wrote: > On Thu, Sep 12, 2013 at 09:55:51AM -0500, inode0 wrote: > > On Thu, Sep 12, 2013 at 7:59 AM, Ralph Bean wrote: > > > Hm, its not worth doing if we're going to make it complex like this. > > > I think we should just drop it. No fedmsg broadcast for votes, only > > > for election period opening/closing and only for election results > > > publication/retraction by the admin (with obviously no user > > > participation data included). > > > > > > It is just not important enough to: > > > > > > 1) cause anyone any worry. > > > 2) bother engineering a complicated "compromise" solution. > > > > > > If someone wants to argue that we still try to make it happen, I'll > > > hear that and implement it if a consensus is formed. (FWIW, > > > personally I'm still all for it). > > > > I thought triggering off logging into the election app would be easier > > and at least in my case is a compromise that I would be comfortable > > with even without any opt-in/opt-out addition beyond what you have > > already made available globally. > > It needs to be something else than logging in, maybe, visit the vote page > logged > in. > That should be easy enough to do in nuancier-lite (and we'll see about > elections). > > Works for me :) A fresh idea came up in #fedora-apps: What if we nix fedmsg for voting all together, but we supply a link in each election page: "Claim the badge for voting" that you can click to, well, get the badge. This way no tracking is done whatsoever and we can also give the "I voted" sticker to only people who want it. pgpdgg987WX3i.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Login to Koji
On Fri, Apr 19, 2013 at 11:37:16AM -0600, Kevin Fenzi wrote: > - Setup your own fedmsg consumer to look for the messages and do > whatever you want on getting them. email you? If you want help doing this, feel free to ask in #fedora-apps on freenode. http://www.fedmsg.com/en/latest/consuming/#naive-consuming pgpamTmiWIXnX.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Login to Koji
On Fri, Apr 19, 2013 at 07:51:37PM +0200, Thomas Moschny wrote: > 2013/4/19 Kevin Fenzi : > > It's true that you cannot do that from the command line interface. > > > > However, there's a bunch of other ways to get that info: > > > > - Subscribe to the koji recent builds rss feed: > > http://koji.fedoraproject.org/koji/recentbuilds > > and alert on whatever builds you care about. > > > > - Join the #fedora-fedmsg channel on irc and setup notify for whatever > > packages you care about and what part of the build (since it will > > send a message on build start, build end, success or failure, tagging > > into tag, etc). > > > > - Setup fedmsg-notify on your desktop and set it to look for the same > > above messages. > > > > - Setup your own fedmsg consumer to look for the messages and do > > whatever you want on getting them. email you? > > > > IMHO we should really move to using fedmsg for these things instead of > > a non standard difficult interface in a specific app. ;) > > Agreed in principle. On the other hand, all these possible solutions > require something running on my side permanently :( In theory, the infrastructure team could build a webapp that: 1) Allows you to manage centralized notification preferences. 2) Listens to the bus and sends emails as appropriate. It could be cool. We could host it at, say, apps.fedoraproject.org/busmail. I've created a ticket to track it as an idea. If you're interested in having such a thing around, please chime in there with a :+1: and any special requirements: https://github.com/fedora-infra/fedmsg/issues/134 pgpmINkKm2LvI.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
New Fedora Tagger
Last week the infrastructure team launched a new version of Fedora Tagger[1]. It is a webapp that allows users to upvote/downvote tags on packages as well as rate packages themselves. The data will end up getting pulled into yum repo metadata by the bodhi masher and into the Fedora Packages[2] indexer to improve search results. Fedora Tagger is also one of our first attempts at "gamification". You earn "points" by voting and rating and there's a leaderboard on which you can muscle for first place(!) This new version is quite a bit of a rewrite. The original version was written on top of the TurboGears2 framework; this new one is written on Flask instead. The rewrite has given us an opportunity to more clearly define the API[3], (many thanks to pingou). This affords us the opportunity to write tools against it: Pierre is working on a desktop tagger application[4] and we've been in some conversation with Richard Hughes about using it for gnome-software[5]. Other new features and bugfixes aside from the API cleaning: - OpenID FAS Login for security and convenience. - You can now cast your rating on packages (not just tags on packages) - The scoring system is more complicated. Adding new tags is worth more points than voting on pre-existing tags. - oddshocks contributed a nice link to the bug tracker from the main page. - After some deliberation[6] on how to go about it, you can actually view packages with no tags when anonymous now. - There used to be some weird focus-stealing bugs when using hotkeys. Those have been eliminated. Try it out, help improve package search, and climb your way to the number-one tagger spot! [1] - https://apps.fedoraproject.org/tagger/ [2] - https://apps.fedoraproject.org/packages/ [3] - https://apps.fedoraproject.org/tagger/api/v1/ [4] - http://blog.pingoured.fr/index.php?post/2013/03/27/GNOME-tagger [5] - http://blogs.gnome.org/hughsie/2013/03/05/gnome-software-overall-plan/ [6] - https://github.com/fedora-infra/fedora-tagger/issues/65 pgpEqh_wqf0Rh.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: New Fedora Tagger
On Tue, May 14, 2013 at 12:43:34PM +0200, Richard Marko wrote: > On 05/14/2013 05:32 AM, Ralph Bean wrote: > > Try it out, help improve package search, and climb your way to the > > number-one tagger spot! > > > > It takes too long to load the next card after user clicks. You should > probably preload more cards or load them asynchronously. I agree. Filed this to track it: https://github.com/fedora-infra/fedora-tagger/issues/92 pgpwz7t6xUCrE.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [Modularity] BPO - the great UI that shows you everything
On Fri, Jul 01, 2016 at 06:14:00PM +0200, Adam Samalik wrote: > Thanks for the response. I agree, asking you "I am building something I > haven't described, how do you want to use it?" might have not been the best > idea... So please, let me try that again and better. :-) Thanks Adam :) > I have created a wiki page [1] that briefly describes the BPO component, > what data would be available, and the main three possible functions. > > > > > > > * Should there be a 'developer' or 'end user' type here? Ie, is it > > expected that they would want to look at this to see what the latest > > version of some module they care about is, or if there's new ones > > that might be coming along soon? Or is that another tool? > > > It would be probably both. But I would focus mainly on developers in the > early stage. Later, there might be something similar to what you described > for the end user. > > > > > > * Depending again on the kinds of things this can report on, > > infrastructure might be interested in it. Could we query it via > > nagios to let us know about problems in module building or testing ? > > > If you would use something like this, I would be happy to include it in the > BPO. > > > > > > * Modules can depend on other modules right? If so, a way to see that > > tree of dependencies in building would be nice (ie, moduleA depends > > on moduleB, and moduleB is currently rebuilding for foo, moduleA > > should show that it's pending rebuilding after that, etc) > > > Yes. This should also be there. > > > > [1] https://fedoraproject.org/wiki/Modularity/BPO Here are some thoughts on the context. Currently, when a packager packages a new upstream release, then build it for rawhide and then they think "what stable releases to I want to also build and ship this for?" Maybe all of them? Maybe just F24? The point is that the packager thinks about it, knows what they're doing, and then does it. Then, about 24 hours later, releng scoops up whatever has been done. - For rawhide, pungi builds the repos and ships it out. - For stable releases, bodhi mashes repos, and ships them out. The most grizzled veterans will rightly balk when I say, "it's easy to know what state an update is in." But.. it's more or less linear. Was it patched but not built? Was it built but not added to an update? Was it in an update but not yet pushed? Is it pushed but not yet on the secondary mirrors? Etc.. In the Modularity Working Group (for various reasons) we're talking about building automation services on top of koji that will automatically rebuild modules based on new available components (these are rpms) (and only sometimes, based on policy). Furthermore, we're hoping to break some of the releng tasks (like the 24 hour nightly compose/push) out into ad hoc tasks that happen alongside, shortly after builds of intermediary components are done (triggered by message bus events). So, that's hard to do. We're working on trying to get it right. One side effect of deploying it is that it's going to be super confusing for packagers to look at this whole thing and figure out what state a patch is in. Say I patched a CVE in component X. Has it been rebuilt into modules L, M, and N? Did it fail in module O's buildroot? If those have been built, which have been shipped? That's all from the developer standpoint who starts from a patch. Release engineering would want a similar kind of question to be answerable: if we have a patch that fixes CVE blah-blah-blah, has that been built into all the artifacts we ship now? Can we say that we've fixed it across the board so we can write a press release? We'll have data scattered all over the place that, when put together, can answer questions like this: some in koji, some in PDC, some in bodhi, some in mirrormanager. The idea here is to make this 'BPO' service (the Build Pipeline Overview service) something that can make those questions easily answerable in one place. In architecture terms, it is like a 'data mart' (convenient access to data that comes from the 'data warehouse', which is bigger and harder to interface with). signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
[Modularity] Messing around with building modules
Hi all! First, check out the logs/minutes from today's Modularity WG meeting: https://meetbot.fedoraproject.org/teams/modularity_wg/modularity_wg.2016-08-30-15.00.html We identified that we needed a doc on how to fool around with our prototype build infrastructure (partly staging, partly a dev environment). We wrote this up which should help if people want to try it out: https://fedoraproject.org/wiki/Modularity/HowToBuildAModuleInStaging Let us know in #fedora-modularity if/when something about it doesn't work and we'll take a look together. :) Cheers- -Ralph signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: [Modularity] Messing around with building modules
On Wed, Aug 31, 2016 at 10:32:39AM +0200, Adam Samalik wrote: > We definitely needed something like that, great! > > Do you think it would make sense to split the instructions into two parts? > Something like: > > 1. Prepare your environment to make it work with our dev infra - "the stuff > you won't need to do in the future" > > 2. Build a module - "The actual workflow" > > I guess might make it easier for people to understand it/see it less > complicated more quickly. And then we could even provide a Vagrantfile with > everything from the first part prepared. > > Does it make sense? Yeah, sounds good to me. :) It's a wiki, so if anyone has time to take that on, please feel free to make the edits. signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Changing bugz.fp.o's alias (again)
A month ago, I switched over the http://bugz.fedoraproject.org alias from the current pkgdb bugs app[1] to the new "packages" app[2]. There was a response from the community that this shouldn't have happened during that phase of the release cycle and that the new app was broken and too slow[3][4]. I reverted the alias to point again to pkgdb. I've since done some work to fix bugs and speed up the new app and would like some feedback if you could provide it. It is up in our staging environment at: https://apps.stg.fedoraproject.org/packages/ If I were to switch over the alias again to the new packages app, the https://bugz.fedoraproject.org/kernel alias would redirect to something like: https://apps.stg.fedoraproject.org/packages/kernel/bugs/all/ Some details: I put cacheing in place. If you hit a page and it is slow the first time, it should be fast for subsequent requests. The expiration is set to 5 minutes, so changes to bugs in bugzilla during that time won't show up. After the expiry, a request for new data will fire off a background thread to refresh the cache. Again, the motivation behind switching the alias from the pkgdb app to the "packages" app is that the pkgdb app's code is older and getting harder to maintain. We are trying to prune (delete) non-essential parts of pkgdb's code in order to one-day rewrite only the core components on a more modern stack. Thanks in advance for any feedback. Cheers- -Ralph [1] - https://admin.fedoraproject.org/pkgdb [2] - https://apps.fedoraproject.org/packages [3] - http://lists.fedoraproject.org/pipermail/devel/2012-December/174956.html [4] - http://lists.fedoraproject.org/pipermail/devel/2012-December/175008.html pgpj4ISR4_juo.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Changing bugz.fp.o's alias (again)
On Wed, Jan 16, 2013 at 05:11:34PM -0700, Jerry James wrote: > On Wed, Jan 16, 2013 at 10:45 AM, Ralph Bean wrote: > > I've since done some work to fix bugs and speed up the new app and would > > like > > some feedback if you could provide it. It is up in our staging environment > > at: > > > > https://apps.stg.fedoraproject.org/packages/ > > I tried looking up a package I maintain, gap. The pages certainly > look nice. The main page shows that the latest build is > 4.4.12-5.fc18, which hasn't been true since September. Does the > staging environment have a snapshot of data from a few months ago? It does. Technically the packages app doesn't maintain any state outside of its 5 minute JSON cache, but it is querying bodhi in which is operating on an older snapshot. One could check it to verify at https://admin.stg.fedoraproject.org/updates > I tried clicking on the "Relationships" tab, since I didn't know what > that was. It thought deeply for about a minute, and then said: > > "Error loading the data for this page element" The "Relationships" tab relies on some data that's not available in stg, unfortunately. If you check the production instance, I believe it does work: https://apps.fedoraproject.org/packages/gap/relationships > I clicked on the "Changelog" tab. It said: > > "This package has no Changelog entries." > > ... which is false. If that's due to limited data in the staging > environment, then no problem, otherwise there's a bug somewhere. Correct! :) https://apps.fedoraproject.org/packages/gap/changelog > I clicked on the "Contents" tab to see what is in there. It has been > doing its sparkly "Loading" thing for several minutes now with no > obvious signs of progress. What is that supposed to show? It should show the files installed when you install the package, for example: https://apps.fedoraproject.org/packages/gap-core/ > Are comaintainers shown anywhere? I can't seem to find a list, except > by clicking through to pkgdb. No, but that's a good idea. I've created a ticket for it; we'll have to figure out how to fit it into the UI smoothly. https://fedorahosted.org/fedoracommunity/ticket/406 > Just a little spelling note, since the word is on every page: > "caching" does not contain an "e". Doh! Thanks for that. It is fixed in git now. pgpknPRWW1Qno.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Updating python-requests in epel6
I'm going to be bumping python-requests in epel6 from 0.11.1 to 0.14.1. If you are using python-requests and think this will cause issues for you, let me know so we can work out a solution. pgpRRqi0OEQnf.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Review Swap Request
I'm working on the unbundling effort for python-requests. One stepping stone in that path is the following review request (for which I am soliciting potential reviewers): https://bugzilla.redhat.com/show_bug.cgi?id=907688 That one is the highest priority, but there are a few other reviews I'd like to promote. This first one is needed for python-moksha-hub's latest test suite: https://bugzilla.redhat.com/show_bug.cgi?id=909644 And this second one is needed for python-tw2-core's latest test suite: https://bugzilla.redhat.com/show_bug.cgi?id=914793 If you have any interest in swapping reviews (or other labor) please let me know. Thanks- -Ralph pgp_DMOq6cjRX.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: review swap
Hi, this is a test message. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F18, efi-bootable live images
This is just a test message. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Planned Outage: Rebuild fedora-packages xapian db - 2015-01-21 18:00 UTC
There will be an outage of the 'fedora-packages' service starting at 2015-01-21 18: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 '2015-01-21 18:00' Reason for outage: The xapian database for Fedora Packages has gotten out of sync and the only way we have to right it at the moment is to rebuild it entirely. See https://lists.fedoraproject.org/pipermail/infrastructure/2015-January/015424.html Affected Services: Fedora Packages - https://apps.fedoraproject.org/packages pgpZvlKd7zxXK.pgp Description: PGP signature ___ devel-announce mailing list devel-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel-announce-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Claiming Fosdem 2015 Badge
On Mon, Feb 02, 2015 at 10:55:40AM +0100, Remi Collet wrote: > Hi, > > Is there any way to get the Fosdem 2015 badge ? > > The URL retrieved on the Fedora booth is already not working anymore.. Here's the original ticket for the badge: https://fedorahosted.org/fedora-badges/ticket/334 eischmann, pingou, and puiterwijk are admins of the badge.. so speak to one of them or perhaps post your request in that ticket. pgpzxY3wmN1Gw.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
All packagers to be added to the new notifications system
As previously announced[1], the infrastructure team is going to be adding all of the members of the packager group to the new fedmsg notifications system (FMN)[2]. It is currently an opt-in system, and this event will just invert things to make it opt-out; you can still disable notifications from it in the web interface. The cut-over will happen next week on Wednesday, February 11th. Thank you, Ralph Bean [1] https://lists.fedoraproject.org/pipermail/devel-announce/2014-September/001434.html [2] https://apps.fedoraproject.org/notifications/ pgpGFpMitqgdo.pgp Description: PGP signature ___ devel-announce mailing list devel-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel-announce-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
New Upstream Release Monitoring Systems
I'm proud to announce that the Infrastructure team has finished deploying the first iteration of our replacement for the older, wiki-based Upstream Release Monitoring tools this week. You can read about the details of the trio of systems[1] now used to coordinate upstream release monitoring on the same old wiki page. Names of systems: - pkgdb is the familiar Fedora Package DB https://admin.fedoraproject.org/pkgdb It provides some flags used by the other systems. - anitya is the web app running at https://release-monitoring.org It is responsible for scraping upstream release sites looking for new releases. - the-new-hotness is a backend daemon that responds to fedmsg messages about upstream releases. The bugs filed in bugzilla look much the same as they did before, but for packagers there is one thing to note: the process of getting your package(s) registered for upstream release monitoring has changed. Please see the instructions[2] on the wiki page. Old packages that were listed on the wiki page have been imported to release-monitoring.org and have had their monitoring flag set in pkgdb. New packages added to Fedora now have their monitoring flag set to True by default and a script attempts to map them to an upstream project in release-monitoring.org automatically. If you want new upstream releases monitored for your package(s), you must: - Add the upstream project to anitya[3]. - Map the upstream project to a Fedora package in anitya[3]. - Enable the monitoring flag for that Fedora package in pkgdb2[4]. Note also that it is now possible to get notifications about upstream releases without bugs being filed in bugzilla. To do this, add your projects to release-monitoring.org and configure your Fedora Notifications (FMN)[5] account while leaving the monitor flag set to False in pkgdb[4]. If you encounter bugs or have requests for enhancement, as always please do file them[6][7][8].. and if you're having problems with a particular package there is a place to list those[8] also on the wiki page. [1] https://fedoraproject.org/wiki/Upstream_release_monitoring#Details [2] https://fedoraproject.org/wiki/Upstream_release_monitoring#TLDR.3B_Get_Packages_Monitored [3] https://release-monitoring.org [4] https://admin.fedoraproject.org/pkgdb [5] https://apps.fedoraproject.org/notifications [6] https://github.com/fedora-infra/anitya [7] https://github.com/fedora-infra/pkgdb2 [8] https://github.com/fedora-infra/the-new-hotness [9] https://fedoraproject.org/wiki/Upstream_release_monitoring#Requesting_Help signature.asc Description: PGP signature ___ devel-announce mailing list devel-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel-announce-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: New Upstream Release Monitoring Systems
On Tue, Feb 24, 2015 at 12:33:29PM +0100, Petr Hracek wrote: > In our project called rebase-helper https://github.com/phracek/rebase-helper > we would like to analyze a new upstream version against an old upstream > version > and let user now what is changed. E.g. Binaries are missing, soname bump > change, header files are missing etc. > > Is there any possibility how to integrate a tool (e.g. rebase-helper) to > upstream release monitoring system? Wow. This looks great and I'd love to have it integrated into the-new-hotness (that's the Fedora-specific daemon that files bugs and tries scratch builds). The relevant code is here: https://github.com/fedora-infra/the-new-hotness/blob/develop/hotness/buildsys.py#L78-L123 Want to try your hand at adding it in? Stop by #fedora-apps when you have time to chat about it and we can work on the details if you like. We're entering infrastructure Alpha freeze later today, so we wouldn't be able to push this out for a few weeks at the earliest. signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
PkgDB and the ArbitraryBranching Change
Hello, As part of the Factory 2.0 and Modularity efforts[1], we’ve been developing a plan to migrate to an “arbitrary” branching model from our current model of one branch per release (as had been discussed at Flock and DevConf[2]). The main motivation behind this is to enable functionality required by Modularity[3] and to ultimately reduce some package maintenance burden. For some packages, it makes sense to have only a single branch that feeds into multiple releases. For other packages, it makes sense to have multiple branches which correlate with multiple upstream minor releases. Today, our source branches are tied to the distro release, via PkgDB. We want to decouple that and use modules to put it all back together again. To make this happen requires significant infrastructure changes. Our proposed plan[4] is to decommission PkgDB entirely and to replace it with a combination of PDC[5] and pagure over dist-git. (Tangentially, getting pagure over dist-git to play nicely with PkgDB was a challenge. This route gets us to a pull-request interface for spec files quicker.) We have brought this Change to FESCo[6][7][8] who expressed general agreement on the project but also concern that the community may be caught by off guard by the removal of PkgDB. As part of this change, we have proposed a timeline[9] that outlines the steps we plan to take to actually proceed with the migration. Please review that if you have time and provide feedback. We are most concerned with missing scripts/tools that may rely on PkgDB’s API. If you can think of any that we may have overlooked, please let us know and we will add it to the timeline! We are meeting again with FESCo next Friday, June 2nd, where a decision will be made on the Change. Any feedback before that would be greatly appreciated. Ralph and Matt, From the so-called Factory 2.0 team [1] https://fedoraproject.org/wiki/Infrastructure/Factory2 [2] https://youtu.be/5gqccjyjwFk?t=26m27s [3] https://docs.pagure.org/modularity/ [4] https://fedoraproject.org/wiki/Infrastructure/Factory2/Focus/ArbitraryBranching [5] https://fedoraproject.org/wiki/Changes/ProductDefinitionCenter [6] https://fedoraproject.org/wiki/Changes/ArbitraryBranching [7] https://meetbot.fedoraproject.org/teams/fesco/fesco.2017-05-19-16.00.html [8] https://meetbot.fedoraproject.org/teams/fesco/fesco.2017-05-26-16.00.html [9] https://fedoraproject.org/wiki/Changes/ArbitraryBranching#Timeline signature.asc Description: PGP signature ___ devel-announce mailing list -- devel-annou...@lists.fedoraproject.org To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: PkgDB and the ArbitraryBranching Change
On Mon, May 29, 2017 at 12:41:57PM +0200, Miroslav Suchý wrote: > Dne 26.5.2017 v 21:42 Ralph Bean napsal(a): > > Any feedback before that would be > > greatly appreciated. > > PkgDB handles Koschei and upstream monitoring settings too. How I can do that > after the migration? The Koschei devs have a feature that will let you manage the koschei settings in the koschei web ui. For upstream monitoring (hotness), we're going to extract the current settings and add them ad a yaml file in dist-git repos for packages that have this turned on. We had issues for this in our backlog but they failed to make it to the timeline in the wiki. I've added them just now. > Does this change somehow affect fedora-packages (aka Moksha) > https://apps.fedoraproject.org/packages/ ? Eh, it does. That's one we missed -- thanks! https://github.com/fedora-infra/fedora-packages/blob/develop/fedoracommunity/connectors/pkgdbconnector.py We'll need to patch that to make requests to the pagure API here too. signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: btw and Monitoring functionality ? Re: PkgDB search / info functionality
On Mon, Jun 12, 2017 at 01:09:28PM +0100, Sérgio Basto wrote: > Hello , pkgdb also have Monitoring settings, Koschei integration, > timeline and Anitya , where do we have this on Pagure over Dist-Git ? The Koschei integration is going to move into Koschei's web UI. (Koschei actually already has this functionality, it is just turned off in Fedora's instance so that it only integrates with pkgdb instead. The Koschei team will just enable that config switch). For upstream release monitoring, we're going to move the values into the dist-git repo in the master branch, in a yaml file. the-new-hotness (which is the only tool which references those values) will have to be re-tooled to look for the values in the new location. signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: RFC: Simply the retirement procedure - trigger on dead.package
On Wed, Nov 27, 2013 at 07:46:28PM +0100, Till Maas wrote: > On Wed, Nov 27, 2013 at 12:35:13PM -0600, Bruno Wolff III wrote: > > On Wed, Nov 27, 2013 at 19:21:53 +0100, > > Till Maas wrote: > > > > > >What are your opinions about this? I already checked with Dennis > > >Gilmore, he is ok with this. > > > > Is there a fail against doing this in released versions? (Unless > > there is a legal reason to do the retirement, we wouldn't want to do > > that for a package in a release.) > > It will be done only for Rawhide and Branched (until the Final Change > Deadline) and maybe EPEL if desired. Wether or not to e.g. retire > packages for other releases without blocking them in Koji needs to be > decided. > > Regards > Till Sounds like a good idea to me. Also seems like it is important enough to run inside the infrastructure environment so that it can be monitored. The #fedora-apps team has been working on pkgdb2 which the authors hope to deploy shortly after the F20 release. Restricting retirement rights to the automated process shouldn't be a problem. pgp5W05osEnNh.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Retiring my gnome-shell search providers
Hello, A while ago, I wrote a trio of gnome-shell search providers: https://apps.fedoraproject.org/packages/gnome-shell-search-fedora-packages https://apps.fedoraproject.org/packages/gnome-shell-search-github-repositories https://apps.fedoraproject.org/packages/gnome-shell-search-pinboard They once worked, and beautifully. I had big plans. Now, though, I can't muster the time to modernize and maintain them. None of them work against our current version of gnome-shell. All three have bugs filed against them. Is anyone interested in taking over any of them (both as Fedora package maintainer and as upstream?) If not, I plan to retire them in the next few weeks. pgptKozb6Os8N.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Koschei false positives?
On Mon, Feb 22, 2016 at 08:59:24PM +, Christopher wrote: > I occasionally get notifications from Koschei about my packages failing to > build. When I look ( > http://koji.fedoraproject.org/koji/taskinfo?taskID=13071213), I see a > python stack trace which looks like it has nothing to do with my package's > build. Rather, it looks like Koschei itself failed. Usually these problems > fix themselves on their own without me needing to touch my package(s) at > all. > > It'd be nice not to get package failure notifications from Koschei when > Koschei itself is at fault and not my package. I realize this might be hard > to tell sometimes... but perhaps there's something which can be done here? Good idea! Can you open a ticket on the koschei issue tracker about it? https://github.com/msimacek/koschei/issues signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: changing project homepage in apps and pkgdb
On Thu, Apr 07, 2016 at 07:44:21PM +0200, Pierre-Yves Chibon wrote: > On Thu, Apr 07, 2016 at 05:12:19PM +0100, Dave Love wrote: > > How do you change the homepage listed in a project's apps page and > > "upstream" in pkgdb (e.g. in > > https://apps.fedoraproject.org/packages/powerman and the different one > > in https://admin.fedoraproject.org/pkgdb/package/rpms/powerman/)? > > pkgdb sync the info from the meta-data in yum's repository on a weekly basis. > So just update the spec file, build it for rawhide and pkgdb will be updated > (iirc the cron runs on Friday). > > For fedora-packages, I don't know. When you change it in the spec file, pkgdb will notice on a cronjob and update itself (like Pierre said). When that update happens, it publishes a fedmsg message. Here's an example: https://apps.fedoraproject.org/datagrepper/id?id=2015-d84267ec-10ae-41db-b4dc-d777e796771e&is_raw=true&size=extra-large fedora-packages has a cache updater that listens to fedmsg and notices that. It *should* rebuild its entries in response to the change, but when I looked just now I discovered that that was not the case. Here's the patch that fixes this for the future: https://github.com/fedora-infra/fedora-packages/pull/234 signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: RFC: Fedora Docker Layered Image Guidelines
On Fri, Apr 29, 2016 at 12:59:40PM -0400, Matthew Miller wrote: > On Thu, Apr 28, 2016 at 05:52:44PM -0500, Adam Miller wrote: > > Another point to note is that we need to determine how this should be > > handled > > in BZ components for bug reporting as well as for filing review requests. > > Maybe a "Fedora Containers" bugzilla product, so we have a different > namespace from RPMs? That sounds like a great idea to me. Similarly, we have a docker/ namespace in pkgdb, from which we could pull the default contact for bugs on a component in the Fedora Containers product (as well as the list of watchbugzilla people). signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: F26 Self Contained Change: Module Build Service
Hey, sorry I didn't respond sooner. I failed to see this hit the list. Responses follow inline, below. On Mon, Nov 07, 2016 at 07:22:12AM -0500, Josh Boyer wrote: > On Mon, Nov 7, 2016 at 4:13 AM, Jan Kurik wrote: > > = Proposed Self Contained Change: Module Build Service = > > https://fedoraproject.org/wiki/Changes/ModuleBuildService > > > > Change owner(s): > > * Ralph Bean > > > > > > We will deploy an instance of the Module Build Service to production > > in Fedora Infrastructure. Other teams will use this service to produce > > some "modular" content for the Fedora 26 release. > > > > > > == Detailed Description == > > We will deploy an instance of the Module Build Service (MBS) to > > production in Fedora Infrastructure. Other teams will use this service > > to produce some "modular" content for the Fedora 26 release. > > > > In short, the MBS is a workflow orchestration service on top of koji. > > When a user submits a request for a new module build: > > > > * A new tag is created in koji for that module build. > > * A module-build macros package is synthesized and built in the new > > buildroot. > > * The buildroot is linked with other module tags that it has declared > > dependencies on. > > * RPMs to be included in the module are rebuilt from source in the new tag. > > Can you explain this in more detail? Yes. See below. > How do layered modules work here? Is that what you mean by "buildroot > is linked with other module tags"? Yes. To be more clear, there are two types of module relationships: There is a "depends" relationship where one module depends on another. What this means at build-time is that the buildroot of the second module is added to the buildroot of the first. In koji terms, the tag associated with the build of the second module is added to the tag inheritance hierarchy of the build tag of the first module. There is an "includes" relationship (that we haven't implemented yet), where one module includes another. The implementation will not involve tag inheritance. The sources of the rpms in the second module will be rebuilt in the buildroot of the second module. We will end up using this second type of relationship to build what are being called "module stacks". For F26, we will be looking primarilly at building the "generational core" stack. https://communityblog.fedoraproject.org/base-runtime-generational-core/ > Can modules built via MBS span releases, or are you strictly limiting > it to the f26 repos for base packages? (E.g. can a module declare a > dependency on an older package found in f25 and have it rebuilt into > the module repo?) For F26, no. In the future, yes. For starters, we're trying to *not* use f26 repos for the base packages. Instead, we're manually bootstrapping an initial base-runtime module, and future builds of the base-runtime module will declare a dependency on previous iterations. For F27, we'll fork the f26 generational-core stack, and future modules will be built against both of those two generational-core stacks, the aim being portability. > If all packages in a module are rebuilt from source, and we have a > variety of modules that all include the packages, doesn't this > increase the storage requirements over what we have today > significantly? Without policy or restriction, yes. For F26, the base set of modules we're building will have a very small number of packages (well, as small as we can get them. As I understand it, the current base-runtime has 3000 packages in it, but they think they can get it down to 400. Ask them! Better, help them.) Note that, for distribution, I expect that for F26 we won't impose any load on the distribution network (on the mirrors). We're just producing one compose of a subset of our total package universe, and it's not getting updates. This is tiny. In the F27 timeframe, if we're not careful about the way we carve up modules, we could get an unsustainable increase in demands on buildsystem resources (storage, cpu, etc..). If instead we are careful about that, then I think we'll still see an increase, but we can keep it in the sustainable ballpark. To help keep us honest about this, please engage with the Modularity Working Group (that team is going to be looking at guidelines and stuff like that, again, in the F27 timeframe). > Are modules built on all architectures? (The answer should be yes, > otherwise we will face significant boot strapping issues.) Yes. (FWIW, our dev instance is only doing x86_64 at the moment, but koji is our primary backend and we'll be inheriting whatever architecture policy is in place in production there, once we get the
Re: F26 Self Contained Change: Module Build Service
On Mon, Nov 07, 2016 at 05:55:21PM -0500, Ben Rosser wrote: > On Mon, Nov 7, 2016 at 4:13 AM, Jan Kurik wrote: > > > For the Fedora 26 timeframe, we will lock down the users who can > > submit to the MBS to a small number of Modularity WG members. This is > > not ideal, but the thought is that we want to limit the amount of spam > > that the MBS will impose on the production koji instance - we don't > > want to interfere with the general release of Fedora 26. > > > > Is the intention then that users will be able to install modules on their > system and have things work within the Fedora 26 timeframe, or would that > not be possible until Fedora 27, assuming nothing slips? It seems like that > would require at least one other change proposal (probably a system-wide > one). I think you've got it. The intention in *this* Change proposal is not about providing modules that you can install at runtime. It's about producing an installable image and one basic yum repo from a set of base modules in the buildsystem. It may be that one of the other teams around will submit proposals for some PoC "user space" modules to be built and distributed for F26, but that's beyond what I'm aiming for here. > I ask as someone who's aware that Modularity is being worked on but not too > clear on what it's actually going to wind up looking like and how my system > / our package collection is going to change as a result. By which I mean, I > understand the goal and basic concept (split packages into higher level > units), but I'm iffy on the implementation details, and if we're at the > point where things are going to start getting deployed in upcoming releases > I'd like to read more about them. > > A lot of the wiki pages on modularity [1] seem to be focused on "why is > modularity a good idea" or "how do I contribute to modularity projects", > but neither of these is quite what I'm looking for. Is there a "Fedora > Modularity for current developers" writeup somewhere? (by which I mean > "Fedora developers" in general). Yeah, this is right in line with some of what Josh was pointing out elsewhere in the thread. We're going to have to get some serious "module guidelines" along with some (hopefully limited) changes to the existing packaging guidelines for F27. The stuff here, again, is about focusing on the base modules, making sure we can build them, combine them, produce an image from them, and seeing if it boots. If we can do that, it's good enough (in my opinion) to move to the next step of thinking how we can usefully modularize the rest of the distro. That said, here are some writeups that help lay the basis for that work: - This is kind of a "glossary": https://fedoraproject.org/wiki/Modularity/Getting_Started/Building_modular_things - This is a kind of theoretical overview of what I'm trying to do in practice with this Change: https://fedoraproject.org/wiki/Modularity/Getting_Started/Constructing_a_modular_distribution - This doesn't have many solutions, but it does raise a lot of the problems we'll have to solve in the F27 timeframe: https://fedoraproject.org/wiki/Modularity/Architecture/Module_versioning_and_branching *NOTE - these pages look really short, but there are sub-pages if you look at the ToC. > Ben Rosser > > [1] https://fedoraproject.org/wiki/Modularity signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: ABI gate: internal-only shared object
On Tue, Jan 23, 2018 at 10:32:49AM +0100, Pierre-Yves Chibon wrote: > On Mon, Jan 22, 2018 at 01:57:34PM -0700, Jerry James wrote: > > Here's something I didn't expect from the new ABI gate. Which, before > > I go further, I think will be a great idea nearly all of the time. I > > think avoiding unintentional ABI breaks in stable releases is a worthy > > goal. > > > > But ... I maintain a package called gap. It provides what amounts to > > a scripting language for doing certain types of math. It comes with a > > bunch of addon packages that provide specific mathematical > > capabilities. Most of them are written solely in the scripting > > language, but a few have to interface with external libraries. When > > that is required, these packages build a small internal-only shared > > object to act as the glue between the external library and the > > scripting language. > > > > I've got a pending update for one of these packages that fixes some > > bugs. It has been caught by the ABI gate: > > https://bodhi.fedoraproject.org/updates/FEDORA-2018-e45a7bb9a7 > > > > There is no danger in pushing this to stable, since the only consumer > > of the changed ABI is inside the same package. Now what do I do? Are > > ABI changes completely disallowed in all circumstances? Is there a > > button somewhere that says, "I am aware of the danger of pushing this > > to stable and I have verified that nothing will break in this case"? > > We just sent an announcement about this, sorry for being late on this. > > Basically, you can "waive" test results using waiverdb-cli (dnf install > waiverdb-cli) which will allow the update to go through despite of the failing > test. > We're working on putting this into bodhi itself for easier use. FYI, here's the change for the Bodhi UI: https://github.com/fedora-infra/bodhi/pull/2095 signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: ABI gate: internal-only shared object
On Tue, Jan 23, 2018 at 02:21:02PM +0100, Adam Williamson wrote: > On Tue, 2018-01-23 at 10:32 +0100, Pierre-Yves Chibon wrote: > > > > We just sent an announcement about this, sorry for being late on this. > > > > Basically, you can "waive" test results using waiverdb-cli (dnf install > > waiverdb-cli) which will allow the update to go through despite of the > > failing > > test. > > We're working on putting this into bodhi itself for easier use. > > Note, just waiving this kind of failure one-by-one doesn't seem like > the proper fix for this to me. Patrick told me yesterday that he'd seen > or been told about a different (I think) but similar case; I think > there may be kind of a generic issue with the ABI diff test checking > the ABI of shared objects that aren't actually 'public' in any > meaningful way. We should look at that as a generic issue. I'm sending > a mail to qa-devel@ to flag this up to the Taskotron devs. We could > consider dropping this test from the gating list again until this is > looked into... I've removed the abicheck requirement from the greenwave policies for now until we know more: https://infrastructure.fedoraproject.org/cgit/ansible.git/commit/?id=465f155d140a9fbe34f0f51dbfc2137b2900a6f8 signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: ABI gate: internal-only shared object
On Tue, Jan 23, 2018 at 08:13:02AM -0500, Matthew Miller wrote: > On Tue, Jan 23, 2018 at 10:32:49AM +0100, Pierre-Yves Chibon wrote: > > We just sent an announcement about this, sorry for being late on this. > > > > Basically, you can "waive" test results using waiverdb-cli (dnf install > > waiverdb-cli) which will allow the update to go through despite of the > > failing > > test. > > We're working on putting this into bodhi itself for easier use. > > Can someone who knows what they're talking about put this into > https://fedoraproject.org/wiki/Package_update_HOWTO?rd=PackageMaintainers/UpdatingPackageHowTo#Handling_feedback_from_automated_tests I added some more detail just now. signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: ABI gate: internal-only shared object
On Tue, Jan 23, 2018 at 06:37:56PM +0100, Rafael dos Santos wrote: > On 23 January 2018 at 18:20, Ralph Bean wrote: > > I've removed the abicheck requirement from the greenwave policies for > > now until we know more: > > https://infrastructure.fedoraproject.org/cgit/ansible.git/commit/?id= > > 465f155d140a9fbe34f0f51dbfc2137b2900a6f8 > > > > Do we have to do anything to proceed? I still seem not able to push my > update to stable. Hopefully the Bodhi maintainers can have a look; Bodhi may be caching the decision here. IIRC, there's a cronjob to synchronize on the Bodhi side. signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Test gating enabled in Bodhi
On Tue, Jan 23, 2018 at 06:35:45PM +0100, Rafael dos Santos wrote:
> I get this error after clicking the authorization link:
>
> [16450:16491:0123/182437.407698:ERROR:browser_gpu_channel_host_factory.cc(120)]
> Failed to launch GPU process.
> Created new window in existing browser session.
> 127.0.0.1 - - [23/Jan/2018 18:24:37] "GET
> /?error_description=Unknown+client+ID&error=unauthorized_client HTTP/1.1"
> 200 47
> Traceback (most recent call last):
> File "/usr/bin/waiverdb-cli", line 11, in
> load_entry_point('waiverdb==0.4.0', 'console_scripts', 'waiverdb-cli')()
> File "/usr/lib/python2.7/site-packages/click/core.py", line 722, in
> __call__
> return self.main(*args, **kwargs)
> File "/usr/lib/python2.7/site-packages/click/core.py", line 697, in main
> rv = self.invoke(ctx)
> File "/usr/lib/python2.7/site-packages/click/core.py", line 895, in invoke
> return ctx.invoke(self.callback, **ctx.params)
> File "/usr/lib/python2.7/site-packages/click/core.py", line 535, in invoke
> return callback(*args, **kwargs)
> File "/usr/lib/python2.7/site-packages/waiverdb/cli.py", line 102, in cli
> if not resp.ok:
> AttributeError: 'NoneType' object has no attribute 'ok'
ACK. Just resolved this one now. Can you try again?
(You may need to visit https://id.fedoraproject.org/logout first.)
signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Test gating enabled in Bodhi
On Tue, Jan 23, 2018 at 10:33:01PM +0100, Dominik 'Rathann' Mierzejewski wrote: > On Tuesday, 23 January 2018 at 20:16, Matthew Miller wrote: > > On Tue, Jan 23, 2018 at 12:25:56PM -0600, Rex Dieter wrote: > > > > There are three tests that must pass in order for updates to go to > > > > stable: > > > > 0. dist.depcheck - to make sure the update's dependencies are available. > > > > 1. dist.abicheck - to make sure the update's ABI remains stable in a > > > >given Fedora release. > > > ... > > > > Finally, if it turns out you need to push an update through despite of > > > > the > > > > test results, you can do so using waiver-cli (dnf install waiverdb-cli). > > > > We are working on integrating this into Bodhi itself, making this > > > > easier. > > > I think it unwise to make item 1 a mandatory item at this point. I'd > > > argue > > > a large number of packages do not provide public api/abi that's worth > > > worrying about in this regard. > > > > I think we should definine a set of packages where we care about this, > > and enable it on a case-by-case basis and make it advisory otherwise. > > That makes sense. How about we start with critical path packages? > Alternatively, libraries which a lot of of other packages depend on > would be good candidates. A thought - we need a defined process for changing and proposing changes to the greenwave policy. Right now, it reflects a proof of concept list that "we just made up" to get this up and running. At the moment, anyone in the 'sysadmin-qa' group is able to make changes to it. Should FESCo be involved? QA? FPC? I want to fix tooling issues, but don't want to be the policy arbiter. Let's get ourselves unblocked for now and then start figuring out some process around this stuff. signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: What to do when test gating in bodhi fails (no test results found)?
On Mon, Mar 19, 2018 at 12:23:49PM -0700, Adam Williamson wrote: > On Mon, 2018-03-19 at 15:57 +0100, Pierre-Yves Chibon wrote: > > On Mon, Mar 19, 2018 at 03:41:15PM +0100, Dan Horák wrote: > > > On Mon, 19 Mar 2018 14:06:56 +0100 > > > Dan Horák wrote: > > > > > > > On Sun, 18 Mar 2018 20:25:31 +0100 > > > > Fabio Valentini wrote: > > > > > > > > > On Sun, Mar 18, 2018 at 7:13 PM, Michael Cronenworth > > > > > wrote: > > > > > > On 03/18/2018 01:02 PM, Fabio Valentini wrote: > > > > > > > > > > > > > > I've looked at waiverdb-cli too, but since no tests seem to have > > > > > > > run at all, it looks like the wrong tool for the job: > > > > > > > I don't want to push an update despite a failed test, I want to > > > > > > > push my update despite no test data being available ... > > > > > > > > > > > > > > > > > > Randy said the tests refresh every 6 hours and/or every time the > > > > > > update is edited. Neither seemed to have occurred for you. > > > > > > > > > > Exactly. The "no test results found" status in bodhi hasn't been > > > > > refreshed in over 10 days now. > > > > > > > > > > Bodhi also displays that all these tests were successful, bit still > > > > > blocks the update because "no test results found", which is > > > > > obviously just wrong. > > > > > > > > > > A manual lookup in resultdb shows me that the tests have in fact > > > > > been run and have all passed: > > > > > > > > https://bodhi.fedoraproject.org/updates/FEDORA-2018-200708ae05 is in > > > > the same situation, all tests are green, but "no test results found" > > > > is reported. It's not very user friendly ... > > > > > > and https://bodhi.fedoraproject.org/updates/FEDORA-2018-71350d90a7 is > > > even more interesting with "The update can not be pushed: 1 of 2 > > > required tests not found", but the listed tests are again all green. No > > > idea what's missing from the output. > > > > All the tests can be green if the "important" ones are missing, they don't > > show > > :( > > > > The important ones are the ones defined in the policy that gates packages > > and > > are listed here: https://fedoraproject.org/wiki/CI/gating_updates > > > > waiverdb-cli should now support waiving missing results, I'm > > double-checking it > > and see if we can document it at: > > https://fedoraproject.org/wiki/Package_update_HOWTO#Handling_feedback_from_automated_tests > > next to the other examples. > > It is also still the case that unpushing and re-pushing the update > should re-trigger the tests in Taskotron, at the cost of re-setting the > karma and 'wait time' clocks for the update (so you'll need to either > get positive karma or wait 7 or 14 days before being able to push it, > from the time of the re-push). > > One obvious easy win here would be to change the "No test results > found" text, as it's clearly confusing. It could be something like "No > results found for blocking tests", perhaps? We could even give Bodhi > the ability to list the names of the 'expected' blocking tests, and > have the text show that somehow, whether as a hyperlink or perhaps just > as a mouseover or something? Yeah, the text is misleading. Greenwave supplies that "summary" line, and agreed - it should be updated to be more informative on its own. This came up in decathorpe's issue thread here: https://pagure.io/greenwave/issue/141 FWIW, greenwave does supply the list of missing and/or failed testcase names in its API response back to Bodhi. Surfacing those more granular details in the Bodhi UI would be good. signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Trouble with Waivers
On Mon, Mar 26, 2018 at 08:53:41AM -0500, Michael Cronenworth wrote:
> I have attempted to create waivers for two updates, but they are still
> unable to be pushed. What have I done wrong?
>
> https://bodhi.fedoraproject.org/updates/FEDORA-2018-c5a0e704d6
> https://bodhi.fedoraproject.org/updates/FEDORA-2018-ec1108333e
>
> $ waiverdb-cli -t dist.rpmdeplint -s '{"item": "wine-3.4-1.fc28", "type":
> "koji_build"}' -p "fedora-28" -c "This is fine"
> Created waiver 94 for result with subject {"item": "wine-3.4-1.fc28",
> "type": "koji_build"} and testcase dist.rpmdeplint
It looks like you did the right thing to me.
IIRC, Bodhi checks back with Greenwave once every 6 hours, so you'll
have to wait for that window to close for Bodhi to notice the change.
(The plan is to have Bodhi listen to Greenwave's bus messages which
would eliminate wait period like this.)
signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: notificati...@fedoraproject.org
On Fri, Mar 23, 2018 at 07:15:36PM +, Sérgio Basto wrote: > Hi, > > I have a suggestion. After some confusions that I have made related > with notifications with a big delay . > > Please add the date of notification on the notification . > > Thanks, > -- > Sérgio M. B. Makes sense. Can you file that as a RFE here? https://github.com/fedora-infra/fmn/issues signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: 'endless' stream of "greenwave is a GO on glusterfs-4.0.0-2...." emails
On Thu, Mar 22, 2018 at 05:34:23PM -0700, Kevin Fenzi wrote: > On 03/21/2018 01:52 PM, Kaleb S. KEITHLEY wrote: > > On 03/21/2018 04:45 PM, Kevin Fenzi wrote: > >> On 03/20/2018 11:02 AM, Kaleb S. KEITHLEY wrote: > >>> > >>> I've rec'd about 30 of these in the last hour or so, fedora-28, > >>> fedora-27, fedora-26, and fedora-28-modular. > >>> > >>> Would someone please make them stop > >> > >> You can do so. > > > > I think you misunderstood what I was asking. > > ah, I did. sorry. > > > > I'm fine with getting _one_ notification. Or maybe even five. > > > > But I have probably 50 in my inbox after all was said and done. All from > > one build. > > Yeah, that seems... wrong. > > CCing Ralph here, perhaps he can comment or other greenwave developers. Yeah, the tl;dr is that Bodhi greenwave needs to be taught that an f26 build only makes sense in the f26 policy. Today, it receives notice about a f26 build and publishes messages about all the policies it has that might apply to that build (f28, f27, f26, etc..). Dan is taking a look at refactoring it to know a bit more about the things its being asked about (builds, updates, ..) which should end up cutting way down on this spam. https://pagure.io/greenwave/issue/126 > > kevin > -- > > > > >> > >> Go to: > >> > >> https://apps.fedoraproject.org/notifications > >> > >> login and select email > >> > >> There should be a ruleset on the right called: > >> "Events on packages I own" > >> > >> Click on it to edit it. > >> > >> On the right now there should be a long list of possible messages, one > >> of them is "Greenwave decisions" > >> > >> Click on "Greenwave decisions" and then "add this rule" > >> > >> Now there should be a "Greenwave decisions" rule on the left in your > >> ruleset. > >> > >> Under that is a "!Negate" button. Click on that to make the rule be a > >> negation rule instead of a matching rule. > >> > >> Now you should no longer get any greenwave emails. > >> > >> Sorry this is so confusing an interface. It really needs a re-write with > >> input from some design folks, but we just haven't had the cycles to do > >> so yet. > >> > >> kevin > >> > >> > >> > >> ___ > >> devel mailing list -- devel@lists.fedoraproject.org > >> To unsubscribe send an email to devel-le...@lists.fedoraproject.org > >> > > ___ > > devel mailing list -- devel@lists.fedoraproject.org > > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > > > > signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: [Modularity]: Service levels and EOL expectations?
> Is there an active plan on figuring out these Service Levels? Is there > a ticket? Is there a specific person who owns this? I think we need at > least a preliminary understanding of what goes here for the F27 beta > (freeze on Sept. 9th, so... I guess by then?) Thanks for starting this. I'm not aware of a ticket or a responsible party at this point. +1 to working towards formalizing this. > I'm assuming "Service Levels" will include options like: > > * This module strives to be very stable and we will backport patches > > * This module tries to be stable but occasionally we may make breaking > changes with FESCo approval when it's the only option for a security > update (this matches the current Fedora updates policy at > https://fedoraproject.org/wiki/Updates_Policy#Security_fixes) > > * This module promises only a subset of functionality to remain the > same. For example, it will include a certain command line program but > doesn't promise that output of that program will aways be identical. > > * This is a development-stream module which makes no promises! (E.g, it is > Rawhide.) > > Is that the kind of thing others are expecting? Or was this to be more > like "security", "security+bugfix", > "security+bugfix+enhancements"? FYI - we had to put some initial SL values into the database to seed the branch migration. Our existing 'master', fedora, and epel branches needed values in the new database. Here are the ones we added: - rawhide - Our thought was that the 'rawhide' SL would signal whatever rawhide means today: more or less tracking upstream. The master branch of all packages got this SL applied in our migration. - bug_fixes - See security fixes below. - security_fixes - This, along with bug_fixes, was a generic SL that got applied to all "fedora" branches (f26, f25, etc..). - stable_api - This one got applied to all of the epel branches. https://pdc.stg.fedoraproject.org/rest_api/v1/component-sla-types/ The real meaning of these values isn't documented anywhere and so they should be taken with a grain of salt. They are something that we can and should change if FESCo (or releng?) or the packager group at large decide to organize our SLs along some other basis. > *Or*, is it something like "best effort", "sig maintained", > "core > critical path", "edition critical path", "spin critical path"? > > I can see the first idea (the * points above) as most useful to > end-users. The third idea is more useful for *us*. > > I'd also like to propose a policy for EOLs. I assume that some modules > will have undefined EOLs, and I think that's okay. There should be some > mechanism and rules for adding one (amount of notice expected, what to > do if we can't meet that expectation, how the tools will present the > addition of an EOL). When a specific EOL is given, though, I'd like a > rule which says that that EOL is aways a month after the planned > traditional Fedora release dates — so, June and November, basically. > (We could choose something like "The last Tuesday in June or November"; > I don't care specifically.) Also, EOL should be treated as a "no sooner > than" date, so if we slip the corresponding release, we could add a > week or two to the upcoming module EOLs. > > That way, users and admins aren't treated to an explosion of arbitrary > days where action is needed to stay on a current stream. Instead, they > can plan for annual upgrades as we do now. (I also expect the > "platform" module to follow the current Fedora release cycle, right?) > > Perhaps there could be an exception made to this rule for modules with > the "development stream" Service Level. Or, maybe those would just have > no defined EOL — like Rawhide today. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Module Stream "Expansion"
This is a writeup on a problem we’re facing with modularity, and some ideas on how to resolve it. # The "Problem" Imagine I have an **httpd module**. To simplify things, let’s say that this module has only one stream: **2.4**. Today, in the modulemd for this module, I declare build and runtime dependencies like this: dependencies: buildrequires: platform: f26 requires: platform: f26 This works. Now, imagine that Fedora 27 comes along. I want the httpd module to be installable on f27, so I update those streams to point to f27. But now I can’t ship updates to f26 anymore! Uh oh. ## Just use more streams? We could just ask packagers to create more streams to deal with this. httpd wouldn’t have a 2.4 stream. It would need to have a f26-2.4 stream and a f27-2.4 stream. But, this gets us exactly back into the place we were **before** we had arbitrary branching! You need to have as many branches for *every component* as you have releases of the distro (or, as you have "products"). N! ## Solution: "Input" Modulemd Syntax Changes We’re going to extend the modulemd syntax to allow specifying multiple dependencies in an "input" modulemd (the one that packagers modify). When submitted to the build system, the module-build-service (MBS) will *expand* these values under the hood, and submit **multiple** module builds to itself based on the expansion. Here are some examples of modulemd files (maintained by humans) that might be submitted to the MBS. Build on **all** active streams of the platform module. dependencies: buildrequires: platform: [] Build on **only** the f27 and f26 platform streams. dependencies: buildrequires: platform: [ f27, f26 ] Build on all active streams of platform **except** for the f26 stream. dependencies: buildrequires: platform: [ -f26 ] The following syntax, which builds on **only** the f26 stream, will still be supported: dependencies: buildrequires: platform: f26 -- Take the following example (described above): dependencies: buildrequires: platform: [ f27, f26 ] Submitting this modulemd to the MBS would in turn generate **two** module builds: one of our httpd module against the f27 stream and another against the f26 stream. Each module build would be associated with its own unique "flattened" *output* modulemd file that specifies exactly which platform stream it was built against. # New Problems Having **multiple** module builds for a single dist-git commit of a modulemd file poses new implementation problems. ## NSV uniqueness Today, we uniquely identify a module build in *a variety of systems* with **--** (NSV) where version is derived from the dist-git commit timestamp. Here we’ll have an httpd-2.4 module built on f26 and an http-2.4 module built on f27: two different module builds with the same name, stream, and version. How can we tell them apart? We will introduce a new value called the **context** of a built module and include it in the modulemd metadata that gets carried with the built module. * For user facing cases (dnf installation) it will generally be hidden. The old NSV value will still appear. If a user ever needs to surface the value, client tooling can find it in the modulemd metadata. The additional identifier will give users access to explicit pointers to the content that is installed: * For cloning a machine. * For comparing two installed hosts. * For reporting bugs. * Some build and compose time systems will have to be modified to use the context as part of a new unique identifier. **NSVC** will be the **---**. The systems in question are PDC, koji/brew, pungi, and bodhi. The context value will be a **hash**, generating as the first step in the build process (but after expansion). Consider what metadata needs to be hashed: we think that hashing the whole modulemd is problematic, because the modulemd can and will be modified after build time. Therefore, the *context_hash* value will need to be derived from only the stuff that uniquely identifies the build and runtime context of the module -- name, stream, version and crucially, its dependencies ## Buildtime/Runtime Dep Correlation Another problem. We now have input modulemd files for a single stream that can expand buildtime dependencies to ‘f27’ and ‘f26’, but what about the runtime dependencies? Consider the following yaml file: dependencies: buildrequires: platform: [f28, f27, f26] requires: platform: [f28, f27, f26] With our thinking caps on, this should obviously generate three module builds (one that buildrequires f28 and run requires f28, a second that buildrequires f27 and run requires f27, and a third for f26). The naive cross-product of all streams is not valuable; the MBS needs some logic to **correlate** the build time requirements with the run
Re: Bugzilla auto-CC
Found it. The fix needs to land in pagure itself. See the infra ticket for more details. https://pagure.io/fedora-infrastructure/issue/6315 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Bugzilla auto-CC
:) Pierre was able to hotfix pagure prod with the watchers fix. I confirmed that the sync script worked correctly on the nodejs-accepts package - it set the default cc list to the nodejs sig mailing list stored in FAS. I started a full run to reset all projects, but it takes quite a while to complete. Should be all fixed up when that's done. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Tekton pipeline for Fedora RPM builds in Konflux
Florian Weimer wrote: > * Ralph Bean: > > I think you're interpreting the situation correctly. Upstream, we > > documented a decision to build those artifacts from source in > > https://konflux-ci.dev/architecture/ADR/0046-common-task-runner-image.html, > > discussed > > https://github.com/konflux-ci/architecture/pull/217. Downstream in RH, > > we're tracking the related work to actually do it in > > https://issues.redhat.com/browse/KONFLUX-5564 (the JIRA project isn't > > open atm, but we intend to make it so; that's underway). It isn't > > explicitly called out that we'll build against Fedora binaries or on > > Fedora infrastructure there; with the current plan we'll be building > > it in Konflux on Red Hat infrastructure, some things against ubi and > > and some against fedora. > Thank you for sharing this background. It's not really explicit in the > description of ADR 46 as far as I can see, but I assume another goal of > this change is to reduce the amount of mystery binaries as well, and > mirroring external dependencies into stable storage first? Yeah, that's the way I see it too. I read that intent in the ADR in the decision line "Build and release via Konflux, hermetically if possible" which to me implies "build from source". > > With that plan, you'd end up with a task runner image that is an > > upstream Konflux binary. A straightforward rebuild of that upstream > > task runner image on the Fedora cluster, so that you have your own > > binary, is possible. (Same goes for all other Konflux images.) > Doesn't reference-by-hash make it rather hard to swap out images because > the rebuild necessarily changes the hash? Or are these references just > URIs and Konflux computes are resource locator from that? (Like the > "http://www.w3.org/TR/html4/strict.dtd"; in DOCTYPE declaration in > historic HTML documents.) > This has implications for sharing sources with downstream distributions. Imagine upstream konflux builds binaries of all its task runner images and it builds tekton bundles (OCI artifacts) of all of our tasks. A pipeline run refers to the bundles, which instruct the cluster which task runner image to use. If Fedora rebuilt only the task runner images, then yes it would be hard or impossible to employ them if you were still using the upstream Konflux tekton task bundles. Rebuilding the task runner images means that you also have to rebuild the tekton task bundles to refer to them - and finally, the Fedora flavor of the rpm build pipeline will need to refer to those task bundles. I'd use the same git-submodule pattern for this. -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-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/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Tekton pipeline for Fedora RPM builds in Konflux
I think you're interpreting the situation correctly. Upstream, we documented a decision to build those artifacts from source in https://konflux-ci.dev/architecture/ADR/0046-common-task-runner-image.html, discussed https://github.com/konflux-ci/architecture/pull/217. Downstream in RH, we're tracking the related work to actually do it in https://issues.redhat.com/browse/KONFLUX-5564 (the JIRA project isn't open atm, but we intend to make it so; that's underway). It isn't explicitly called out that we'll build against Fedora binaries or on Fedora infrastructure there; with the current plan we'll be building it in Konflux on Red Hat infrastructure, some things against ubi and and some against fedora. With that plan, you'd end up with a task runner image that is an upstream Konflux binary. A straightforward rebuild of that upstream task runner image on the Fedora cluster, so that you have your own binary, is possible. (Same goes for all other Konflux images.) If that's what we end up wanting to do, I'd use this pattern for it to try to keep the maintenance burden low: https://konflux-ci.dev/docs/patterns/git-submodules/. I wonder where and how we would draw the line between things to rebuild for the Fedora instance and situations where you accept a third-party binary? For example, we currently deploy on a Red Hat Openshift cluster (ROSA). Rebuilding all of those openshift images is surely a step too far, no? -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-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/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
