Re: Removing "Severity" from New Bug form
Le 08. 12. 15 14:16, Jonathan Wakely a écrit : >> Dropping it is ok I think. > > Yes, even for the valid "enhancement" cases a maintainer who triages > the report could set that easily enough. If maintainers still use the severity field to triage bugs, then it should not be dropped. It would be much easier to restrict the ability to edit the severity field to users with editbugs privs (basically users with a @gcc.gnu.org account + a few other accounts). Frédéric
Who played with the GCC Bugzilla git repo?
Hello, Someone played with the GCC Bugzilla git repo last week with no real reason: Author: root Date: Fri Oct 7 15:28:43 2016 + snap-data Looks like the goal was to drop all CSS and JS files in data/assets/. Why? There is no reason to play with the data/ directory. This directory contains data generated by Bugzilla and is automatically cleaned up (and regenerated) by checksetup.pl when needed and so doesn't need to be cleaned up manually, and definitely not via git. data/ is in .gitignore for a reason! Moreover, this means that the GCC Bugzilla git repo is no longer in sync with the upstream Bugzilla git repo, because the one who played with git also committed my local changes (I didn't do it for a reason). I can no longer view my local changes, nor can I easily sync both repos with a fast-forward merge (I think). Could these changes be reverted to the exact point I left Bugzilla in May, i.e. 5.0.3 + my patch only? Frédéric
New anti-spam extension enabled on GCC Bugzilla
Hello, I just enabled an extension on GCC Bugzilla which automatically disables reporter's account if their bugs are marked as INVALID and are in the 'spam' component. So if you have enough privileges on GCC Bugzilla to close a bug as INVALID and to move it in the 'spam' component (in the 'gcc' product), you can help disabling these user accounts. It doesn't matter if the bug is closed as RESOLVED or CLOSED. What matters is the INVALID resolution. Note that you won't see any notification that the account has been disabled. That's expected. :) I re-enabled user account creation a few minutes ago, and already 2 new accounts have been created. Both are spammers. I have disabled them already. Note that my extension only disables reporters. It doesn't disable commenters who are also spammers (because we have no way to mark a comment as spam yet. This feature will come with Bugzilla 5.0). For them, admins will have to disable these accounts manually: https://gcc.gnu.org/bugzilla/editusers.cgi You type the email address of the user you want to find, then click on it and type some text in the "Disable text" field. You can also click the "Bugmail Disabled" checkbox to prevent the spammer from getting any new bugmail. Do not forget to click the "Save Changes" once you are done. Good luck! Frédéric PS: Do not hesitate to email me if there is something wrong with my extension.
Account creation disabled on GCC Bugzilla
Hello, I again disabled account creation on GCC Bugzilla due to spammers being still very active. 117 user accounts have been created since yesterday. 102 have been identified as spammers and have been disabled. For the remaining 15 accounts, I have no evidence that they are spammers. At least one of these 15 accounts is valid, so I don't want to blindly disable them all, see https://pastebin.mozilla.org/6263691 for the list of still enabled accounts. 311 bugs have been created on GCC Bugzilla since yesterday. Only 2 are valid bugs. The remaining 309 ones are all spam and have been moved into the 'spam' component and marked as INVALID. Frédéric
Re: Spam again
I added code to GCC Bugzilla last night to collect IP addresses from requests for new accounts. 80% - 90% of requests are coming from the following IP ranges: 62.122.72.x - 62.122.79.x 91.229.229.x 185.2.32.x 185.44.77.x - 185.44.79.x 188.72.126.x - 188.72.127.x 188.72.96.x 193.105.154.x 194.29.185.x 195.34.78.x - 195.34.79.x 195.78.108.x - 195.78.109.x All of them asked for a @wowring.ru account. If some of you want to play with these IP ranges, I would be curious to know where they are coming from. Maybe Russia? GCC Bugzilla is still under attack currently. Bugzilla reports 3-4 new user account creation attempts every *minute*, all for a @wowring.ru account. But @wowring.ru is blacklisted for the last 7 hours so all these attempts fail. Sorry for this morning, I wasn't around to blacklist this email domain sooner. So far, Bugzilla blocked 650 requests for a new account, mostly all for @wowring.ru. I also patched Bugzilla to no longer email the GCC mailing-list when a bug is moved into the 'spam' component. Frédéric
Definition of the Host, Target and Build fields in Bugzilla
Hello, Could one of you give me a short and clear description of each of the Host, Target and Build fields used in GCC Bugzilla? Currently, hovering the field label for these fields in bug reports gives no useful description besides the default message "A custom Free Text field in this installation of GCC Bugzilla". This would help users known what to write into these fields when reporting new bugs. I already fixed the description for the "Known to fail", "Known to work" and "Last reconfirmed" fields. Frédéric
Re: GCC Bugzilla disables caching of linked content
Le 11. 11. 14 20:11, Jonathan Wakely a écrit : > At some point GCC's bugzilla started taking ages to load, because > every single .css and .js file gets a query appended to the URL: > > skins/contrib/Dusk/global.css?1368269827 > > This causes Firefox to constantly re-fetch those pages again and > again, so it takes several seconds to load every. single. page. > > Do you know why this is? 1368269827 is the timestamp when these files were last modified. It's appended to the URL so that your web browser doesn't refetch them if it already has them in cache with this timestamp. So if your web browser refetches them all the time, then you have something wrong with your browser. In my case, pages load very quickly because none of the CSS or JS files are reloaded. You cannot disable this feature. Frédéric
Re: Confirming a bug in new bugzilla?
Le 10. 04. 11 02:19, Joseph S. Myers a écrit : > Likewise. We don't use VERIFIED and CLOSED in GCC, proper text should > reflect the existence of only one closed state with a genuine meaning and > not mention the others (ideally they'd be completely hidden). That's not true. VERIFIED and CLOSED are valid bug statuses used in the GCC Bugzilla. There are 517 bugs with one of these statuses. In reply to Gerald, Bugzilla 4.2 will contain a hook which will let us easily customize the http://gcc.gnu.org/bugzilla/page.cgi?id=fields.html page. For now, if changes are wanted on this page, a bug should be filed in GCC Bugzilla (please CC me) and the template modified via a patch. The patch will have to be backed out before we upgrade to 4.2. Frédéric
Re: Confirming a bug in new bugzilla?
Le 11. 04. 11 01:33, Jonathan Wakely a écrit : > Most of those cases are the reporter changing the status to VERIFIED > after a gcc maintainer has set it to RESOLVED. That doesn't mean the > maintainers use VERIFIED of that keeping it is useful. If they are useless, then they should be removed to avoid confusion and to make queries easier. But if we keep them, then they should be described as any other bug status. An external user cannot guess that they have no special meaning for you. Frédéric
Re: gcc.gnu.org Bugzilla: Perl error Can't locate mro.pm in @INC
Le 26. 01. 11 17:04, Frank Ch. Eigler a écrit : Can't locate mro.pm in @INC > > This may be fixed now, with a hand-made dummy mro.pm file. I think I know what's wrong. I will paste what I wrote at https://bugzilla.mozilla.org/show_bug.cgi?id=675633#c2: email_in.pl requires Email::Reply which requires Email::Abstract which requires mro since 3.003. So if you have Email::Abstract 3.002 or older, you shouldn't get this error. If you have Email::Abstract 3.003 or newer, then this means MRO::Compat (which has "mro") is not correctly installed. Frédéric
Re: Bugzilla shouldn't mangle patches
Le 15. 11. 11 10:50, Jonathan Wakely a écrit : > So I clicked on the attachment link, and I get the patch viewer, > showing me a coloured, side-by-side diff. Very pretty, but no use if > I want to download it to apply it to the GCC source. > > So I clicked on the "Raw Unified" link above the side-by-side view. > That doesn't give me the original patch, it gives me some mangled > version. The pretty diff view is useful for reviewers, which is why the link in the comment points to it. If you want to see or download the original patch, either click on the attachment name in the attachments table itself, or click the View link at the top of the pretty diff page. Being myself a heavy user of Bugzilla for 7 years now, I never used the Raw Unified link. Maybe I should just remove this link from upstream, to avoid this kind of confusion. LpSolit
Re: Bugzilla shouldn't mangle patches
Le 15. 11. 11 13:25, Jonathan Wakely a écrit : > unified link would be useful. For GCC unified diffs are the norm, so > having an extra link to show it in that form (but not accurately) does > seem unhelpful. Feel free to file a bug on GCC Bugzilla, and assign it to me, so that I can remove this link independently of what I decide upstream. :) LpSolit
Re: gcc bugzilla upgrade
Le 07. 09. 10 18:41, NightStrike a écrit : >>> I was working on a gcc bugzilla project upgrade under Daniel Berlin's >>> guidance but have not been able to contact him in a long while. >>> >>> Can anyone give me a current address for him or another dev's name who I >>> can work with? >> >> I thought Frédéric Buclin (copied) is now working >> on this? Perhaps the two of you can sync? >> >> Gerald > > Heh.. I was, too :) Looks like several people offered their help to upgrade GCC Bugzilla, but the process never completed. :) I hope I will be luckier. I filed a bug, see http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43011. There is some traction there. Frédéric
Re: gcc bugzilla upgrade
Le 07. 09. 10 18:51, NightStrike a écrit : > Well, I've been working on it since I got the approval. I just > haven't posted patches yet. Should I stop? If your patches are based on Bugzilla 3.6.x, no way! :) Could you please attach them to bug 43011? Frédéric
Re: gcc bugzilla upgrade
Le 07. 09. 10 19:14, NightStrike a écrit : > So for instance, instead of 2.20+ > 3.6.1, I was doing 2.20 > 2.21, etc. Wow, iterating this way is too long (and 2.21 is a development snapshot, not a stable release). We must jump directly from 2.20 to 3.6.2, else we will go nowhere. The code is definitely too different between 2.x and 3.x to iterate. Frédéric
GCC Bugzilla upgrade to version 3.6.2 in progress
Hi all, A test installation based on a copy of the GCC Bugzilla database (snapshot taken yesterday, September 9) and upgraded to Bugzilla 3.6.2 is now live at http://gcc.gnu.org/bugzilla-test/. Please give it a look, and file bugs related to missing or broken customizations in the new "Bugzilla" product on the test installation, i.e. using this link: http://gcc.gnu.org/bugzilla-test/enter_bug.cgi?product=Bugzilla Note that I didn't port *any* customization yet, so you probably have a lot to say. ;) Those of you who are used to report bugs on installations running Bugzilla 3.x will already be familiar with the new UI. Those who only know Bugzilla 2.x may feel a bit lost at first, but you will quickly see the numerous advantages and features of Bugzilla 3.6 over the old Bugzilla 2.20 one. I will try as much as possible to convert hacks implemented by GCC in 2.20 to supported features, extensions and hooks available in Bugzilla 3.6, to 1) ensure that customizations do not generate unexpected behaviors or bugs, and 2) to make the code more easily maintainable and portable to future releases of Bugzilla. For a list of new features available in Bugzilla 3.6.2, see the release notes at http://www.bugzilla.org/releases/3.6.2/release-notes.html. To track progress on the GCC Bugzilla upgrade, our meta bug is http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43011 Have fun testing the new Bugzilla, LpSolit PS: Those of you who cannot log into http://gcc.gnu.org/bugzilla-test/ because your password is less than 6 characters long must click the "Forgot password" link. You will get an email with a link to follow, from where you will be able to enter a new password (which must be at least 6 characters long, for obvious security reasons. This minimum value of 6 is the standard value for all new Bugzilla installations around the world, not only GCC). For help, you can find me on irc.freenode.net in the #overseers channel.
Re: GCC Bugzilla upgrade to version 3.6.2 in progress
Le 10. 09. 10 12:22, Richard Guenther a écrit : > So - can you enumerate the customizations you didn't bring over? I have no official list of customizations to port to the newer Bugzilla. All I have in hands are the two patches attached to bug 43011, see http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43011. These patches are a diff between the official 2.20 release and what GCC Bugzilla currently has. So I will have to read these patches carefully, extract what's still relevant for 3.6.2, and try to understand what each hack is trying to achieve and port it over to 3.6.2. Based on some discussions I already had, some customizations are no longer needed because they were either rarely used, or nobody understood what they were trying to do. :) A list of already reported bugs is available here: http://gcc.gnu.org/bugzilla-test/buglist.cgi?quicksearch=%3ABugzilla LpSolit
GCC Bugzilla upgrade to version 3.6.2 ready
Hi all, I'm done with the implementation of customizations for the 3.6.2 Bugzilla installation. The test installation, which is based on a copy of the GCC Bugzilla database (snapshot taken on September 9), is live at http://gcc.gnu.org/bugzilla-test/. Please test it, and file bugs related to missing or broken customizations in the new "Bugzilla" product on the test installation, i.e. using this link: http://gcc.gnu.org/bugzilla-test/enter_bug.cgi?product=Bugzilla I prefer you to report bugs *before* the upgrade, not after. If something broken is found after the upgrade, don't complain. :) If nothing severe is found in the coming days, we will probably upgrade the production installation later this week. I think Ian will keep you informed about this. Have fun testing the new Bugzilla, LpSolit
Re: GCC Bugzilla upgrade to version 3.6.2 ready
Le 21. 09. 10 01:18, Jonathan Wakely a écrit : > Oops, I didn't realise that changes to the test installation get > emailed to gcc-bugs and to the users who reported the bug or are CC'd > on it Yeah, it's a production-ready installation, with all features enabled. :) Only bugs filed in the Bugzilla product are not emailed to the GCC mailing-list. I could create a "Test" product, if you want to. LpSolit
Re: Bugzilla outage Thursday, September 23, 18:00GMT-21:00GMT
Le 25. 09. 10 17:10, Jonathan Wakely a écrit : > Was it a conscious decision for the "Add me to CC list" checkbox to be > ticked by default? Yes, because most of the time, when you comment on a bug, other users may react to your comment, or ask for more information, etc... In that case, it's important that you see these comments. But note that Bugzilla 3.6 is controlled by several default user preferences (like this one), which can be overridden by your own preferences. Simply visit this page, and set your user preferences as you like them: http://gcc.gnu.org/bugzilla/userprefs.cgi Of course, these preferences are per user, and will only affect your account (unlike parameters which are global and can only be accessed by administrators). ;) In this specific case, look at the "Automatically add me to the CC list of bugs I change" user preference, and set it to "Never". There are other great features in Bugzilla 3.6. Should I enumerate some of them? :-D Frédéric
Re: Bugzilla not whining [was Re: Bugzilla outage Thursday, September 23, 18:00GMT-21:00GMT]
Le 28. 09. 10 11:25, Dave Korn a écrit : > Before I start, I'd like to thank Frédéric for having done all this work and > got us a nice shiny new bugzilla. Thank you! Thanks again. :) > One minor thing appears to have failed in the transition: although all my > saved searches and whine settings have come across cleanly, I'm no longer > receiving my nightly emails that the whine is supposed to be sending me. Is > it just me, or is something broken? It's not just you, nor is it broken. Last Friday, Daniel Berlin asked me what to do with the cron job for whine.pl, because this script was running from his own account, and while I did the upgrade, I enforced security on Bugzilla which doesn't let him run this script himself anymore. We have to run whine.pl from another account, which I have access to. I thought Daniel would do it himself, but from what you say, he didn't. :) Unless someone from #overseers wants to set the cron job himself, I can do it. #overseers: please let me know. (note that we should add collectstats.pl as well to the cron job, to collect data for old and new charts.) > (While looking for where to report this, I noticed that the "Bugzilla" > product category wasn't carried over from the test installation; Yeah, the initial plan was to create a "Bugzilla" product, move the already filed bugs to this product, and use it for Bugzilla-specific bugs. But when I looked at the older bugs specific to Bugzilla, I realized that it would be a very low-usage product, so I didn't create it, and we use gcc/web instead. If there is enough interest in a separate product for Bugzilla, it would be easy to set it up. Just let me know (again for #overseers). Frédéric
Re: Bugzilla not whining [was Re: Bugzilla outage Thursday, September 23, 18:00GMT-21:00GMT]
Le 28. 09. 10 11:25, Dave Korn a écrit : > I'm no longer > receiving my nightly emails that the whine is supposed to be sending me. This should be fixed now. Let me know if you still don't get nightly emails. Frédéric
Re: GCC Bugzilla upgrade to version 3.6.2 ready
Le 05. 10. 10 06:53, Florian Weimer a écrit : > It seems that the new Bugzilla does not set a Message-ID header when > sending mail. You come a bit late in the game, see http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45818 ;) Frédéric
Re: gcc.gnu.org Bugzilla: Perl error Can't locate mro.pm in @INC
Le 26. 01. 11 11:29, Tobias Burnus a écrit : > Can't locate mro.pm in @INC mro.pm is part of the core code of Perl since version 5.9.5. So it's not available here as sourceware has Perl 5.8.5 installed. Where is this script located? And did you get the exact line and script which threw this error? Frédéric
Re: Bugzilla new bug page
Le 18. 10. 12 14:06, Jonathan Wakely a écrit : > Other bugzillas I've used have a big red text box that very > prominently tells the submitted to search for existing bugs. Do you have an example of such Bugzillas? Mozilla and RedHat have no such big red box. KDE has something closer. > I'd do it myself but I don't know where the relevant pages are. Are > the bugzilla templates in CVS, or only on the server? Only on the server.
Re: Bugzilla new bug page
Le 18. 10. 12 14:27, Jonathan Wakely a écrit : > I'll prepare some mockups for people to look at and see if they like it. Please file a bug and CC me. It's much easier to track progress in Bugzilla than per email. LpSolit
Re: Bug repositories
(Igor jumped into the Bugzilla developers IRC channel, so that's why I heard about this thread.) Ian said: "I'm willing to provide you with a dump of gcc's bugzilla database if you can give me the exact command to run." Sorry, but I have to object! It's not ok to give anyone a plain dump of the GCC Bugzilla database for studies or any other reason without some sanity check. The Bugzilla database contains all the user account passwords and preferences, as well as group permissions. Such a copy of the DB would give the possibility to try to crack the passwords locally, though the encryption is supposed to be very secure. This means that a local access to the DB allows one to skip throttling when someone starts typing the wrong password again and again, decreasing the time needed to crack passwords. Moreover, having access to group permissions means to be able to know who are admins and to try to abuse these accounts in GCC Bugzilla itself. This is a security breach. Bugzilla offers no special tools to generate a sanitized copy of the DB, so one shouldn't try to create a dump of the DB and spread it without a very good knowledge of Bugzilla internals. LpSolit
