Re: Freeze Break Request: fix bugzilla query limited results in review-stats

[Jason L Tibbitts III]

That looks like a lot of change for what should be a one-line change.
Did some unrelated commit sneak in?

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

Re: Mirror Syncing Problem

[Jason L Tibbitts III]

> "R" == Riseops  <" > writes:

R> We've been trying to sync using the quick-fedora-mirror script but
R> we're getting the error below: - When syncing from
R> dl.fedoraproject.org

It would be useful to see the non-comment lines from your
quick-fedora-mirror configuration file.  I suppose it would also be nice
to see the portion of the log showing how rsync is being called, though
I think the configuration file will be enough.

The only guess I can make from what you have given is that maybe you
have modified MODULEMAPPING, or maybe MASTERMODULE, so that it isn't
able to know that the "fedora-epel" module is in a directory called
"epel" under the master module.

In general you should never modify MASTERMODULE unless you're a tier1
mirror yourself and are pulling from fedora-buffet0 instead of
fedora-buffet.  And there's no reason to ever change MODULEMAPPING,
either, unless you're repurposing the script to work with some
non-Fedora mirror setup.

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

Re: MirrorManager changes - report_mirror

[Jason L Tibbitts III]

> "AR" == Adrian Reber  writes:

AR> The problem is that people are reporting different things than they
AR> have.

Well quick-fedora-mirror shouldn't be doing that, since it checks in
what it mirrors as part of a run.  Though I suppose you could
incorrectly set the host it reports as.

AR> This has nothing to do with report_mirror or quick-fedora-mirror.

Well it does considering that you would then be ignoring the data those
things provide (which does take some effort to produce).

AR> Everything the crawler has.

Which is less than what quick-fedora-mirror (or report_mirror) have
access to, and it's also less timely.  And then there's the difficulty
in getting that data out of a mirror that only provides http.  I'd think
checkins would be the preferred way and the crawler would be a backup
check that the mirror is configured correctly.

Anyway, my point is that if the data are insufficient then it's possible
to fix that.  If q-f-m checkins are generally less broken than
report_mirror checkins, then we can make it easy to identify them.  But
sure, if the data simply aren't useful at all, then there is no point in
sending them.

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

Re: MirrorManager changes - report_mirror

[Jason L Tibbitts III]

> "AR" == Adrian Reber  writes:

AR> I would like to ignore report_mirror results for non-private mirrors
AR> in the future.

I don't really see why this would have to be done globally unless we're
just going to abandon the concept of reporting for public mirrors.  Do
you have an issue with quick-fedora-mirror checkins as well or just ones
from report_mirror?  Can I have quick-fedora-mirror provide additional
data so that you can distinguish it from report_mirror?

And if checkins are ignored, then will mirrormanager have to wait until
the next crawl before it knows that my mirrors have new content (even
though that happens within a few minutes after the content is available)?

AR> For private mirrors report_mirror is the only way to
AR> know which content it has, for public mirrors it is not really
AR> necessary as the mirrors are crawled anyway and report_mirror does
AR> not contain enough information anyway right now.

Well, what information do you need?

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

Re: [FBR] Hotfix pagure on src.fp.o

[Jason L Tibbitts III]

> "PC" == Pierre-Yves Chibon  writes:

PC> In order to fix
PC> https://pagure.io/releng/fedora-scm-requests/issue/1078 I would like
PC> to manually apply the following change to pagure on src.fp.o:

I note that we're still not able to import packages with names
containing dots.  I'm not sure if this hotfix wasn't pushed, or if
perhaps it wasn't sufficient.

My guess is that there is another tool involved in this and that one
also needs to be adjusted.

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

Re: State of the Review Server (Fresque)

[Jason L Tibbitts III]

> "AB" == Aurelien Bompard  writes:

AB> My questions are: should we drop it? Rework it? How high a priority
AB> is it really?

Well, I think we would really use... something.  The current bugzilla
based "experience" is basically a mess we've all learned to work around
(or given up on) and I still feel bad for new contributors who have to
struggle with it.  But really, the whole process needs an overhaul and
something that simply codifies the existing process probably isn't the
best way to spend your free time.

A workflow built around pagure and various other pieces of
infrastructure like copr and taskotron which could give some measure of
automatic builds and error checking would be incredibly great but I have
no idea how possible it is.

Then we'd just say "package submissions go into this namespace in pagure
and get hooked up to automated builds and tests and whatnot".  Add a way
for prospective reviewers to see those submissions and some mechanism
for a reviewer (with privileges) to approve a package for inclusion.
Then it's just a simple matter of figuring out how to get the approved
package into the distribution.

But again, I have no idea if any of this is actually possible.  I do
know I'd be able to do a heck of a lot more reviewing work than I do now
(which is basically zero) if I could so things like:

* Click through a pagure listing that shows me just the package which
  are actually building and ready for review

* See everything right there, including a spec file, current rpmlint
  output and things like taskotron checks

* Make quick comments on the spec file

* Star a repo so it shows up in the list of packages I did review work
  on (so I don't forget)

And a whole lot of that seems to be a mashup of what pagure and copr
already seem to do.  Anything that encourages drive-by reviewing and
incremental improvement of submitted packages while hiding packages
which aren't at the point of building properly is a huge plus in my
opinion.

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

Re: The future of pkgdb

[Jason L Tibbitts III]

> "KF" == Kevin Fenzi  writes:

[Using foo-owner@fp.o as the default owner for bugs]
KF> But also disadvantages of people liking to see a name they can point
KF> to about the package or know who is cc'ed on the bug.

For years I've wondered why we don't do that, honestly.  But I think it
might be weird that bugzilla separates the owner of a package from the
owner of a bug, and some of the interactions might be non-obvious.

When I take a bug, will the other maintainers still be notified?  Will
bugzilla send mail to foo-owner as well as CC'ing the maintainers, so
that everyone gets each message twice?

Will someone be able to log into bugzilla as foo-owner?

What happens to bugs marked as private?  If they're private to foo-owner
then how will the actual maintainers see them?

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

Re: New Bodhi beta - please test!

[Jason L Tibbitts III]

> "PR" == Peter Robinson  writes:

PR> Any particular features/chages/fixes we should be looking at in
PR> particular for this release?

Yes, knowing what changes to look for would be great.  Also, having a
more updated snapshot of the database might be useful.

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

Re: Fedorahosted and Trac

[Jason L Tibbitts III]

> "GG" == Grant Gainey  writes:

GG> The problem isn't editing the wiki once we're on GitHub - it's
GG> trying not to lose 8 years of history while getting there in the
GG> first place.

Extract each version as a separate page, convert to markdown (as well as
you can) and commit that?  It should be easily scriptable, but I don't
know if github exposes its wiki as a git tree like pagure does with
tickets or docs.

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

Re: Proposal to mirror Docker images

[Jason L Tibbitts III]

It would also help to have the following information.  The mirrors will
need to have this information in order to make informed decisions.  (I
will also have to make changes to quick-fedora-mirror to accommodate.)

1) How much content will the mirrors need to store?  How will this
   amount change over time?

2) Do you have a plan for placing an upper bound on the total amount of
   data?  (In Fedora things are moved to archive, though that has its
   own problems and of course doesn't really place an upper bound on
   anything.)

3) How much change do you expect per day?  Churn is really important,
   and even now we can come close to the point where the master mirrors
   simply can't feed new content to the tier 1 mirrors fast enough for
   them to keep ahead of the changes we're making.

4) How will this be organized on the master mirrors?  It really should
   be in a separate rsync module, and the archive (if that happens)
   should also be in a separate rsync module.

For some background, I have three mirrors, each identical (1U, 4x4TB
disks, RAID0, cached on SSD using bcache).  I mirror all content from
the master mirrors.  Right now I have about 12TB used, 3.5TB free.  I
could upgrade to larger disks for more space, but of course that costs
money.

Basically we're past the point where we have to carefully consider how
we ask the mirror network for more storage and bandwidth, and any plan
for adding stuff should at least include some projections of disk and
bandwidth usage.

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

Re: Builds from git repo with unpacked sources

[Jason L Tibbitts III]

> "MS" == Michal Sekletar  writes:

MS> Recently, internally they introduced very nice feature that might be
MS> also useful to Fedora packagers. It is the ability to build packages
MS> from exploded sources. Packager no longer uploads tarball to
MS> lookaside cache and maintains patches in dist-git, but points rhpkg
MS> (internal equivalent of fedpkg) to git repo that contains exploded
MS> sources with downstream patches applied on top. This allows for easy
MS> cherry-picking of patches between branches and a ton of other nice
MS> features that make maintainer's life easier.

I know this is the infra list, but as a packaging committee member I
figured I'd comment.

From a packaging standpoint I'd be happy to see something like this
allowed in Fedora, with some caveats (which I'm coming up with on the
fly, so don't hate on me if they're dumb):

1) Probably only if the upstream development model works this way.  If
   upstream expects people to work from tarballs, it's probably better
   to work that way too.  Maybe not, though; I don't really have enough
   info.

2) The builds must obviously be repeatable using just the srpm.

3) The tooling must make it very simple to duplicate the exploded tree
   in which you develop using just the spec, patches, and a checkout
   from upstream.

Also, it would be nice to see how the workflow goes and how it differs
from the way you work with stacked patch applications and
"%autosetup -S git".  I'm sure even a simple doc would be enough to sell
this.

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

Re: Code browser for SRPMs

[Jason L Tibbitts III]

> "KF" == Kevin Fenzi  writes:

KF> Yeah, we would need to at least temporarily unpack it, which is a
KF> lot of cpu and disk space.

I thought that there was some service which already unpacked tarballs in
the lookaside at the time they were uploaded, for the purpose of
checksumming all of the files inside.  I can never remember what it's
called, though.

Anyway, if that still happens then it's the perfect place to do this
kind of thing on a grand scale.

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

Re: [FREEZE BREAK REQUEST] add rsync module for fedora-live-respins

[Jason L Tibbitts III]

> "KF" == Kevin Fenzi  writes:

KF> On Thu, 28 Apr 2016 09:10:46 -0500
KF> Nick Bebout  wrote:

>> diff --git a/roles/rsyncd/files/rsyncd.conf.download-phx2
>> b/roles/rsyncd/files/rsyncd.conf.download-phx2 index f105959..5f5b35f
>> 100644
>> --- a/roles/rsyncd/files/rsyncd.conf.download-phx2
>> +++ b/roles/rsyncd/files/rsyncd.conf.download-phx2
>> @@ -61,6 +61,9 @@ refuse options = checksum comment = Delta isos path
>> = /srv/pub/alt/stage/deltaisos
>> 
>> +[ fedora-live-respins ]
>> + comment = Fedora Live Respins
>> + path = /srv/pub/alt/live-respins
>> ##
>> ## The following are not seen and are limited by IP.
>> ##

KF> Well, I suppose we could do this... we do already have alt so
KF> currently: /fedora-alt/live-respins/ would work. But I guess there's
KF> no harm in adding this to the top level.

Do full mirrors now need to add the module to their rsync configurations
as well?

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

Re: Dropping gitolite and breaking stg

[Jason L Tibbitts III]

> "PC" == Pierre-Yves Chibon  writes:

PC> For a little while now I have been wondering about dropping gitolite
PC> for pagure.  Gitolite has quite a lot of advantages:

I also want to add that the developer of gitolite has worked with us
pretty closely to develop things to meet our needs.  Not that this
should prevent us from moving to something that fits better if that's
what people want to do, but it might be nice to at least talk to the
guy.  Though I doubt there's much anyone could do about it being written
in perl.

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

Re: CSI vars patch for buildaarch64

[Jason L Tibbitts III]

> "ZV" == Zach Villers  writes:

ZV> +csi_purpose: Koji service employees a set
ZV> of virtual machines to build packages for the Fedora project. This
ZV> group builds packages for aarch64 architecture.

FYI, "employs", not "employees".

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

Re: mdapi in our infrastructure

[Jason L Tibbitts III]

> "JLT" == Jason L Tibbitts  writes:

JLT> I guess this hinges on whether having an _srpm_ with the same name
JLT> as one in RHEL would cause an issue for EPEL, even if there's no
JLT> conflict with the binary packages.

Just confirmed that this isn't an issue, since it's already done in a
few cases.

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

Re: mdapi in our infrastructure

[Jason L Tibbitts III]

Well, crap, I guess I was wrong, or the answer is more complicated.  Too
bad.

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

Re: mdapi in our infrastructure

[Jason L Tibbitts III]

> "PC" == Pierre-Yves Chibon  writes:

PC> My problem is more for the package in Fedora also present in RHEL,
PC> thus where we only want the python3 version as otherwise we
PC> conflict.

That's where either you don't build the python2 version on RHEL, by
using a separate spec or with a mass of ifdefs.  I guess this hinges on
whether having an _srpm_ with the same name as one in RHEL would cause
an issue for EPEL, even if there's no conflict with the binary
packages.  I would guess not as I haven't seen any mention of
mass-reviews (or exemptions for such) for python3-* packages in EPEL.

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

Re: About MirrorManager2

[Jason L Tibbitts III]

 NC == Nick Coghlan ncogh...@redhat.com writes:

NC In that general vein, an interesting project Robert Collins
NC introduced me to last year is his lmirror work:
NC https://pypi.python.org/pypi/lmirror

That is quite interesting.  It's obvious that rsync is kind of breaking
down, given that with my current mirroring setup (just running a private
internal mirror) I can rarely get a complete copy across the wire due to
timeouts while receiving the file set.

Not a lot of commits happening upstream, though.  Is this code actually
being used anywhere?

I guess the first step if we want to try to play with this is to get it
packaged.

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

Re: Updated usage needed for process-git-requests script

[Jason L Tibbitts III]

 PN == Parag Nemade pnem...@redhat.com writes:

PN Another question, anyone can reply, why only one person is given
PN this work?

That isn't the case.  For me, one problem is that generally when I check
there aren't any requests to process, because limb takes care of them so
quickly most of the time, so eventually I check less often.  And I'm
kind of busy as well given that it's the biggest holiday in the western
world.

All of this angst over, what, a few days delay?  Why is everyone in such
a hurry, anyway?

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

Re: Updated usage needed for process-git-requests script

[Jason L Tibbitts III]

 PN == Parag Nemade pnem...@redhat.com writes:

PN In simple words no human is required for processing this request.

Absolutely, categorically untrue.

There are cases when it's OK.  Even outside of simple sanity checking,
there are plenty more cases when it's not.  Some of those cases (say,
preventing branching of packages for EPEL when they're present in some
Red Hat product) could be written into code.  Some of those cases
(perhaps tracking down the owners of other branches for ACKs) can't
easily be codified.

Having never done this job I imagine you don't know how difficult or
important it is.  Post-review branching is the last chance an admin has
to prevent poorly reviewed crap from getting into the distro, which
means we actually have to read the reviews (unless they're done by
someone we trust).

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

Re: Updated usage needed for process-git-requests script

[Jason L Tibbitts III]

 PN == Parag Nemade pnem...@redhat.com writes:

PN I have seen after discussing with few members of sysadmin-cvs
PN group that they found script process-git-requests[1] is not working
PN for them and believe only limb knows how to run it. 

That's quite a mischaracterization.  You asked if I could run the queue;
it was 1AM, I ran into an issue and wasn't conscious enough to debug
it.  I'm sure the script works fine; I just haven't done it in a while
and didn't have login credentials cached or something.

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

Re: Updated usage needed for process-git-requests script

[Jason L Tibbitts III]

 KF == Kevin Fenzi ke...@scrye.com writes:

KF This is the wrong location. We should delete it from there.

So that was my problem.  It wasn't some systematic failure; I just
needed to get a fresh checkout from the proper location.

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

Re: Gitolite3 on pkgs01.stg

[Jason L Tibbitts III]

 PC == Pierre-Yves Chibon pin...@pingoured.fr writes:

PC Currently, the people that have shell access to pkgs01.stg, we
PC currently cannot do a simple ssh pkgs01.stg...

Ouch.  I guess everything is going over the console now?

PC Hopefully, we'll be able to fix this.

sshd listening on a different port, if nothing else works?

I think the new package setup process still requires us to ssh in,
so

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

Re: people ssh Banner

[Jason L Tibbitts III]

 KF == Kevin Fenzi ke...@scrye.com writes:

KF Sadly that won't work. The only people who have accounts are those
KF in cla_done + 1 group. So, the people without that don't even have
KF an account, so they can't authenticate. ;(

Is it possible to give them accounts that have no permission to do
anything?  I used to change the shell to /usr/local/bin/terminated,
which printed a message about the account being closed.

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

Re: people ssh Banner

[Jason L Tibbitts III]

 SJS == Stephen John Smoogen smo...@gmail.com writes:

SJS In this case that would be close to a hundred thousand accounts
SJS linked to /bin/noshellforyou for the 3200 that are cla+1.

Just stating a solution.  It would actually work, after all.  Whether
it's worth the annoyance and any potential security exposure, I don't
know.  But if you want to display something to CLA+0 people but not
CLA+1 people then, well, I believe that is the only way to do it.

SJS In the past that was a great way to DOS a machine..

Maybe back in 1994 or something.  I really doubt this is a consideration
these days.

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

Freeze break request

[Jason L Tibbitts III]

Please forgive me if this isn't the right format for this request; it's
been a long time since I've done one of these.

I need to push the following change to the review-stats code through
puppet:

diff --git a/modules/review-stats/files/review-stats.py 
b/modules/review-stats/files/review-stats.py
index 2c59752..e494168 100755
--- a/modules/review-stats/files/review-stats.py
+++ b/modules/review-stats/files/review-stats.py
@@ -205,7 +205,7 @@ def run_query(bz):
 bugdata[bug.id]['hidden'] = 1
 
 # Get the status of each interesting bug
-for i in seq_max_split(alldeps, 500):
+for i in seq_max_split(alldeps, 100):
 for bug in filter(None, bz._proxy.Bug.get_bugs({'ids':i, 'permissive': 
1})['bugs']):
 interesting[bug['id']] = bug

RHBugzilla is pretty broken right now, and I'm working on fixing this
code upstream in a better way which I will push once we unfreeze, but
this is the minimal fix that appears to at least get the script to
complete without throwing proxy errors.  It takes ages to run but it
does eventually finish.

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

Re: Freeze break request

[Jason L Tibbitts III]

FYI, all this does is submit several smaller lists of tickets to a
query.  Currently I need to get the open/closed status of 519 tickets;
passing a list of 500 to bugzilla used to work but no longer does.
Passing 100 seems to work, but still takes ages.  Pretty sure I can do
it better but I wanted to send a minimal change.  This isn't really a
critical service anyway.

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

Re: Freeze break request

[Jason L Tibbitts III]

 SJS == Stephen John Smoogen smo...@gmail.com writes:

SJS I would say drop it down to 50 for the moment.

I can do that; I just picked 100 because I found that 250 was low enough
for things to work so I halved it to add some headroom.  If setting it
to 20% of what works is enough to get me a +1 so I can get this thing
running again, great.

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

Re: Freeze break for post-update hook on pkgs01?

[Jason L Tibbitts III]

 RB == Ralph Bean rb...@redhat.com writes:

RB   1) Run git check-perms /srv/git/rpms --check=post-update --fix
RB on pkgs01 again to fix the handful of repos that are out of sync.

I wouldn't have realized that we were frozen in such a way as to prevent
this kind of thing.  I'd +1 myself but I'm not sure if I have standing
to do so.

RB   2) Apply the following patch in puppet which will add the hook for
RB new repos.

I'd +1 this as well, but if there's controversy I could also modify the
SCM processing script to do this.  It's not, to my knowledge, subject to
any freeze.

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

Re: Freeze break for post-update hook on pkgs01?

[Jason L Tibbitts III]

 KF == Kevin Fenzi ke...@scrye.com writes:

KF Yeah, we are in pre-alpha freeze.  See:
KF 
https://fedorahosted.org/fedora-infrastructure/browser/architecture/Environments.png
KF pkgs01 (where this change would need to happen) is under the freeze.

But that's precisely my confusion.  If we can't change a repository git
hook without a freeze break, then should we also not be processing SCM
requests?  If someone asked me to delete a branch from a repository or
make some other SCM-admin-related change (which admittedly happens
rather rarely), is that also a freeze break?

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

Proper setting for smtp_from in new trac instance?

[Jason L Tibbitts III]

Perhaps I missed it but I didn't see any kind of guide to setting up a
new fedorahosted trac instance so I copied from one other trac where I
have privileges.  That trac has smtp_from set to t...@fedorahosted.org.

The problem with this is that some hosts appear to do SMTP callouts and
reject messages sent with that setting:

May 29 04:42:36 hosted03.vpn.fedoraproject.org postfix/smtpd[17813]:
NOQUEUE: reject: RCPT from XXX: 550 5.1.1 t...@fedorahosted.org:
Recipient address rejected: User unknown in local recipient table;
from= to=t...@fedorahosted.org proto=SMTP helo=XXX

infradead.org is one such host that does this, but it is not the only
one.

It appears that several trac instances are using this setting.  Should I
be using something else or is it possible to get an alias from trac@ to
nobody@ set up so that this will work?

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

Re: RFE: change meetbot log layout (or add an alternate)

[Jason L Tibbitts III]

 MM == Mike McGrath mmcgr...@redhat.com writes:

MM http://meetbot.fedoraproject.org/teams/
MM It's not very well advertised.

What magic gets a meeting into that list?  Because I can't seem to find
any of the FPC meetings there.  I assume there's some bot incantation
that does it which we're not using.

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

Fix to /usr/local/bin/setup_git_package on pkgs

[Jason L Tibbitts III]

This one-character typo seems to be preventing commit mail from being
sent for all newly-created packages.  I've fixed a couple already, but:

$ ls /srv/git/rpms/*/hooks/post.receive|wc -l
92

so I've more to fix.  Not sure if I need +1s to make those changes, but I do
need +1s to push the following fix through puppet.  I'm pretty sure that
this script simply lives in puppet; if there's another more upstream
repository, please let me know and I'll try to get this fixed there
first.

diff --git a/modules/gitolite/files/distgit/setup_git_package 
b/modules/gitolite/files/distgit/setup_git_package
index ebe3165..4b438b2 100755
--- a/modules/gitolite/files/distgit/setup_git_package
+++ b/modules/gitolite/files/distgit/setup_git_package
@@ -111,7 +111,7 @@ popd /dev/null
 # Put our special update hooks in place
 ln -s /usr/share/gitolite/hooks/common/update $GITROOT/$PACKAGE.git/hooks/
 ln -s /usr/share/git-core/mail-hooks/gnome-post-receive-email \
-$GITROOT/$PACKAGE.git/hooks/post.receive
+$GITROOT/$PACKAGE.git/hooks/post-receive

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

Re: [PATCH/RFC] viewvc: Add a note that CVS is read-only

[Jason L Tibbitts III]

Not being in the right group to give plusses to anything, I do have a
question: is it in general OK for a puppet-managed file to overwrite an
rpm-managed file in this manner?  viewvc does not seem to have a
mechanism for files in some config-friendly location to override the
ones in /usr/share.

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

Re: [PATCH] neuter viewvc on cvs.fedoraproject.org

[Jason L Tibbitts III]

Does anyone still keep anything in the cvs/fedora repository?  I did
until recently, but my stuff has all moved into the infrastructure git
repo.  There is plenty of old stuff there that we probably wouldn't want
to just delete, but I don't see why it would need to exposed via viewvc.

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

Re: outgoing port block on fedorapeople.org

[Jason L Tibbitts III]

 JvM == Jeroen van Meeuwen kana...@kanarip.com writes:

JvM Is any outbound NEW connection supposed to be used from
JvM fedorapeople.org accept maybe for a few named sockets on trusted
JvM remote hosts?

Well, some might think it reasonable to pull content to fedorapeople
(wget, scp run on fedorapeople pulling from remote sites) instead of
forcing content to be pushed.  Which would argue for outbound http and
ssh ports, I guess.  Should be easy to just say no to that kind of
thing, though, if the intent is to lock it down.

I also wonder if mounting user-writable filesystems as noexec would be
reasonable.

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