From metatracker at psf.upfronthosting.co.za Sun Nov 5 10:57:29 2017 From: metatracker at psf.upfronthosting.co.za (Berker Peksag) Date: Sun, 05 Nov 2017 15:57:29 +0000 Subject: [Tracker-discuss] [issue644] 'Random Issue' Button isn't working In-Reply-To: <1508803113.44.0.213398074469.issue644@psf.upfronthosting.co.za> Message-ID: <1509897449.72.0.213398074469.issue644@psf.upfronthosting.co.za> Berker Peksag added the comment: >From http://www.roundup-tracker.org/docs/customizing.html#extensions-adding-capabilities-to-your-tracker All files from this dir are loaded when tracker instance is created, [...] It's not clear to me when this was added, but it seems like this is the cause of the bug. I added a global counter in pydevutils.py to test this and it didn't work. Ezio, is there a way to solve this bug? ---------- nosy: +berker.peksag, ezio.melotti status: unread -> chatting _______________________________________________________ PSF Meta Tracker _______________________________________________________ From metatracker at psf.upfronthosting.co.za Thu Nov 9 14:54:48 2017 From: metatracker at psf.upfronthosting.co.za (Berker Peksag) Date: Thu, 09 Nov 2017 19:54:48 +0000 Subject: [Tracker-discuss] [issue644] 'Random Issue' Button isn't working In-Reply-To: <1508803113.44.0.213398074469.issue644@psf.upfronthosting.co.za> Message-ID: <1510257288.61.0.213398074469.issue644@psf.upfronthosting.co.za> Berker Peksag added the comment: Hi John, do you know a workaround to make the random issue extension work again? ---------- nosy: +rouilj _______________________________________________________ PSF Meta Tracker _______________________________________________________ From metatracker at psf.upfronthosting.co.za Thu Nov 9 15:06:05 2017 From: metatracker at psf.upfronthosting.co.za (Berker Peksag) Date: Thu, 09 Nov 2017 20:06:05 +0000 Subject: [Tracker-discuss] [issue634] Only link PR to the bpo that is in the PR title, not the body In-Reply-To: <1497060629.6.0.388698227929.issue634@psf.upfronthosting.co.za> Message-ID: <1510257965.8.0.213398074469.issue634@psf.upfronthosting.co.za> Berker Peksag added the comment: I agree with Mariatta. We should just look for the PR title. As a fallback, we can check the body if we can't find an issue number in the title. ---------- nosy: +berker.peksag _______________________________________________________ PSF Meta Tracker _______________________________________________________ From metatracker at psf.upfronthosting.co.za Fri Nov 10 21:59:40 2017 From: metatracker at psf.upfronthosting.co.za (John Rouillard) Date: Sat, 11 Nov 2017 02:59:40 +0000 Subject: [Tracker-discuss] [issue644] 'Random Issue' Button isn't working In-Reply-To: <1510257288.61.0.213398074469.issue644@psf.upfronthosting.co.za> Message-ID: <20171111025937.9ECE14C068E@itserver6.localdomain> John Rouillard added the comment: Hi Berker: In message <1510257288.61.0.213398074469.issue644 at psf.upfronthosting.co.za>, Berker Peksag writes: >Hi John, do you know a workaround to make the random issue >extension work again? I pulled the source for the bugs.python.org tracker and took a look. The function I got to work better in my demo tracker was: import random from roundup.cgi.actions import Action from roundup.cgi.exceptions import Redirect class RandomIssueAction(Action): def handle(self): """Redirect to a random open issue.""" issue = self.db.getclass('issue') issue_ids = issue.filter(None, {'status': 1}) random.seed() url = self.db.config.TRACKER_WEB + 'issue' + random.choice(issue_ids) raise Redirect(url) def init(instance): instance.registerAction('random', RandomIssueAction) I changed: the way I got the handle to issues from the db the way the list of id's in my tracker instance I was getting tracebacks otherwise. Since you do get redirected to a page on bugs.python.org you obviously aren't getting traceback so this new function may not work. Originally triggering the random action I saw a lot of repeats. My thought was that the random function wasn't so random. The new 1.5.1+ (what will be 1.6) roundup uses more random data than 1.4.20. Addition of nonces to protect against csrf etc. consumes random data. So I added random.seed(). This seemed to increase the randomness of the function. You may want to try adding random.seed() to your existing function and see if that helps. Even after seeding, I still saw duplicates, but there were only 20 issues to choose from. In your case you have 6000+ issues to select from duplicates by chance are reduced. _______________________________________________________ PSF Meta Tracker _______________________________________________________ From metatracker at psf.upfronthosting.co.za Sat Nov 11 00:05:04 2017 From: metatracker at psf.upfronthosting.co.za (Berker Peksag) Date: Sat, 11 Nov 2017 05:05:04 +0000 Subject: [Tracker-discuss] [issue644] 'Random Issue' Button isn't working In-Reply-To: <1508803113.44.0.213398074469.issue644@psf.upfronthosting.co.za> Message-ID: <1510376704.3.0.213398074469.issue644@psf.upfronthosting.co.za> Berker Peksag added the comment: Thank you for your quick response and for your detailed analysis, John. I will attach a patch to implement your suggestions. > My thought was that the random function wasn't so random. The new 1.5.1+ > (what will be 1.6) roundup uses more random data than 1.4.20. Addition > of nonces to protect against csrf etc. consumes random data. Should I open an upstream issue to document this at http://roundup.sourceforge.net/docs/upgrading.html ? _______________________________________________________ PSF Meta Tracker _______________________________________________________ From metatracker at psf.upfronthosting.co.za Sat Nov 11 10:32:03 2017 From: metatracker at psf.upfronthosting.co.za (John Rouillard) Date: Sat, 11 Nov 2017 15:32:03 +0000 Subject: [Tracker-discuss] [issue644] 'Random Issue' Button isn't working In-Reply-To: <1510376704.3.0.213398074469.issue644@psf.upfronthosting.co.za> Message-ID: <20171111153201.827854C03FF@itserver6.localdomain> John Rouillard added the comment: Hello Berker: In message <1510376704.3.0.213398074469.issue644 at psf.upfronthosting.co.za>, Berker Peksag writes: >Thank you for your quick response and for your detailed analysis, John. > >I will attach a patch to implement your suggestions. > >> My thought was that the random function wasn't so random. The new 1.5.1+ >> (what will be 1.6) roundup uses more random data than 1.4.20. Addition >> of nonces to protect against csrf etc. consumes random data. > >Should I open an upstream issue to document this at > http://roundup.sourceforge.net/docs/upgrading.html ? Can you try my patch with and without the random.seed() call and see if it makes a difference on bugs.python.org. If the patch without random.seed() works then there is something different happening on the b.p.o tracker and my test tracker. As I said the code I got from your tracker wouldn't run at all in my installation (context was always None, _klass wasn't a valid property etc.). Given that I had to do surgery to even make it not crash I wonder if there is something else in the code base that I am missing. How the b.p.o tracker executed? I run roundup as a stand alone daemon with a web server front end proxying to the roundup instance. How is b.p.o configured? CGI, stand alone daemon, wsgi, mod_python, zope? I wonder if that makes a difference. _______________________________________________________ PSF Meta Tracker _______________________________________________________ From metatracker at psf.upfronthosting.co.za Sat Nov 11 16:03:43 2017 From: metatracker at psf.upfronthosting.co.za (John Rouillard) Date: Sat, 11 Nov 2017 21:03:43 +0000 Subject: [Tracker-discuss] [issue644] 'Random Issue' Button isn't working In-Reply-To: <20171111153201.827854C03FF@itserver6.localdomain> Message-ID: <20171111210338.E3A034C068C@itserver6.localdomain> John Rouillard added the comment: Hi all: In message <20171111153201.827854C03FF at itserver6.localdomain>, John Rouillard writes: >In message <1510376704.3.0.213398074469.issue644 at psf.upfronthosting.co.za>, >Berker Peksag writes: >>Thank you for your quick response and for your detailed analysis, John. Well it gets more wierd. >>I will attach a patch to implement your suggestions. >> >>> My thought was that the random function wasn't so random. The new 1.5.1+ >>> (what will be 1.6) roundup uses more random data than 1.4.20. Addition >>> of nonces to protect against csrf etc. consumes random data. >> >>Should I open an upstream issue to document this at >> http://roundup.sourceforge.net/docs/upgrading.html ? Hmm, seems roundup is borking something in the random module. I created a default tracker using ./demo.py in a current checkout of the roundup tree. I added 30 issues and my implementation of your random action. I also added: print random.random() print random.random() inside the handler. I get the same sequence every time: 0.8774733181 0.652775856602 I access the http://...?@action=randomurl. That's not right Every import of random is supposed to be seeded with the current time or some os specific random data every time. Then once it's seeded the same instance of random should be updating the random state so the next call to random produces the next random number. AFAICT, what I see should be happening only if something in the code is calling random.seed() with the same value every time the url is accessed. However even when I comment out all of the seed() calls in the roundup code (all located in roundup/cgi/client.py) I get the same results as above. So there are no calls to random.seed in the roundup code base. Restarting the server by rerunning ./demo.py generates a new sequence with different values. Shoving a random.seed() in the handler function is merely covering up something that is broke. I'll keep poking at it to try to figure out why random seems to be losing state, but I am stumped here. _______________________________________________________ PSF Meta Tracker _______________________________________________________ From metatracker at psf.upfronthosting.co.za Wed Nov 22 06:28:29 2017 From: metatracker at psf.upfronthosting.co.za (Martijn Pieters) Date: Wed, 22 Nov 2017 11:28:29 +0000 Subject: [Tracker-discuss] [issue612] Unable to log in with OpenId, "Not authenticated (no session)" In-Reply-To: <1486101428.05.0.334787650816.issue612@psf.upfronthosting.co.za> Message-ID: <1511350109.48.0.213398074469.issue612@psf.upfronthosting.co.za> Martijn Pieters added the comment: I've not been able to use my Stack Exchange OpenID for ages now. Open ID: http://openid.zopatista.com/mj/, which delegates to https://openid.stackexchange.com/user/8c49a3dc-c339-4920-83c5-e5307c0c302e; there is also a vanity URL https://openid.stackexchange.com/zopatista which redirects to the full UUID url. With the Google login button gone, and Launchpad having changed their OpenID urls, I had to request a password reset today just to get back in. ---------- nosy: +mjpieters status: unread -> chatting _______________________________________________________ PSF Meta Tracker _______________________________________________________ From metatracker at psf.upfronthosting.co.za Sun Nov 26 18:07:23 2017 From: metatracker at psf.upfronthosting.co.za (Barry Warsaw) Date: Sun, 26 Nov 2017 23:07:23 +0000 Subject: [Tracker-discuss] [issue645] Searching for open bugs sets the button to all Message-ID: <1511737643.7.0.213398074469.issue645@psf.upfronthosting.co.za> New submission from Barry Warsaw : I go to bugs.python.org, enter `linesep` in the search field and click the 'open' button, then click search. In the resulting page, the button is set back to 'all', even though all the hits are open. This is confusing UI. ---------- messages: 3422 nosy: barry priority: bug status: unread title: Searching for open bugs sets the button to all _______________________________________________________ PSF Meta Tracker _______________________________________________________