We have at least two bugs that need more testing reports on x86:
bug #373491 - Stabilize =sys-kernel/tuxonice-sources-2.6.38-r1
bug #364485 - sys-libs/freeipmi-0.8.9 de-keywording request
If you're using those packages please comment on the mentioned bugs what are your testing results (both positive and negative; without positive report we don't really know whether anyone has tested those).
By the way, feel free to just do the same (test and report) from time to time with x86 bugs.
If you have an amd64 system, please do the same with amd64 bugs.
It's really worth your effort. If the updates have annoying bugs, it's better to defer stabilization until they're fixed rather than annoying many stable users. Similarly, if the updates work for you, it's better if we can just release them sooner and start working on other packages.
November 4, 2011
October 19, 2011
Exhaustive testing of stable reverse dependencies
tl;dr - Developers, if you fix a problem with a stable package and do a version bump, please make sure to open a stabilization request for the bumped version. Many of problems described here have been fixed in the ~arch tree, just the fix was not pushed to stable.
Recently I started testing stable reverse dependencies in a more organized way. I used to go to sites like http://tinderbox.dev.gentoo.org/misc/dindex/, pick a few entries and random, see if they're stable, and emerge them after installing the unstable packages for testing.
That approach had several problems: some of the failures with reverse dependencies were not actually regressions, and many reverse dependencies listed on tinderbox are not marked as stable, which requires time for manual corrections.
Recently I wrote a tool for finding reverse dependencies. It only returns stable packages, and can even randomly choose a smaller number of packages in case of very large set of reverse dependencies (there are many packages depending on gtk+ for example).
My new workflow is to emerge the reverse dependencies first, and remove from list any packages that already have problems. Then I emerge the stable candidates, and re-emerge the reverse dependencies. Any problems that occurs in the last phase is most likely a regression.
So far I haven't really noticed that many regressions, but there are actually existing breakages in the stable tree, usually for less popular packages (that's why more organized testing is useful). Here are some examples of bugs I've encountered:
Recently I started testing stable reverse dependencies in a more organized way. I used to go to sites like http://tinderbox.dev.gentoo.org/misc/dindex/, pick a few entries and random, see if they're stable, and emerge them after installing the unstable packages for testing.
That approach had several problems: some of the failures with reverse dependencies were not actually regressions, and many reverse dependencies listed on tinderbox are not marked as stable, which requires time for manual corrections.
Recently I wrote a tool for finding reverse dependencies. It only returns stable packages, and can even randomly choose a smaller number of packages in case of very large set of reverse dependencies (there are many packages depending on gtk+ for example).
My new workflow is to emerge the reverse dependencies first, and remove from list any packages that already have problems. Then I emerge the stable candidates, and re-emerge the reverse dependencies. Any problems that occurs in the last phase is most likely a regression.
So far I haven't really noticed that many regressions, but there are actually existing breakages in the stable tree, usually for less popular packages (that's why more organized testing is useful). Here are some examples of bugs I've encountered:
- bug #351854 - media-libs/libquicktime-1.2.2 poor programming practices lead to failure
- bug #380409 - dev-lang/ruby-enterprise-1.8.7.2010.02-r1 collides with dev-lang/ruby-1.8.7_p334-r2
- bug #384499 - Please stabilize =dev-lang/tinycobol-0.65.9
- bug #384501 - Please stabilize =dev-perl/Term-ReadLine-Gnu-1.200.0-r1
- bug #384737 - media-tv/dvbstreamer-1.1-r1 fails to install (/usr/bin/install: will not overwrite just-created `.../types.h' with `types.h')
- bug #384863 - sci-chemistry/raster3d-2.7c fails to compile (Error: Expression at (1) must be of INTEGER type, found REAL)
- bug #384869 - app-admin/webalizer should not die on USE=nls and no LINGUAS in pkg_setup
- bug #385265 - Please stabilize =net-misc/arpd-0.2-r1
- bug #385403 - dev-php5/pecl-http-1.7.0-r1 sandbox violation
- bug #385423 - games-simulation/crashtest-1.1 fails to build (fltk-config misuse?)
- bug #387531 - Please stabilize =app-text/zathura-0.0.8.4 to avoid nasty blocker
September 20, 2011
Stabilizations: situation stable
I just checked and x86 and amd64 bug queues are fully under control. I'd even say we're now doing stabilizations faster than maintainers can file new bugs and fix stabilization blockers.
A lot of credit goes to arch team members and arch testers who've been doing a lot of good work in this area. Also, at least for me, the productivity has increased a lot after using better tools from http://git.overlays.gentoo.org/gitweb/?p=proj/arch-tools.git;a=summary
My plans now include better handling of stabilization requests we can't handle yet due to bugs or missing info (I'm going to provide better feedback for the maintainers - just need to adjust my tools a little bit), and then looking for packages that are a little bit behind and should be stabilized.
Arch testers' help is still wanted and very appreciated. Now that bug queues are shorter than they used to be we can do even better testing.
We're on good track towards having a good, stable, and up-to-date tree.
A lot of credit goes to arch team members and arch testers who've been doing a lot of good work in this area. Also, at least for me, the productivity has increased a lot after using better tools from http://git.overlays.gentoo.org/gitweb/?p=proj/arch-tools.git;a=summary
My plans now include better handling of stabilization requests we can't handle yet due to bugs or missing info (I'm going to provide better feedback for the maintainers - just need to adjust my tools a little bit), and then looking for packages that are a little bit behind and should be stabilized.
Arch testers' help is still wanted and very appreciated. Now that bug queues are shorter than they used to be we can do even better testing.
We're on good track towards having a good, stable, and up-to-date tree.
August 30, 2011
www-client/chromium: Kerberos testers wanted
I changed the way Kerberos works in >=www-client/chromium-15.0.865.0.
If you're interested in testing, please emerge that version with USE="kerberos" and see if the Kerberos support works as intended. It'd also be nice to test with various Kerberos implementations (MIT vs Heimdal).
Even if you're not using Kerberos, if something is broken in that version please also file bugs.
The changes implemented in that version should make it work better with revdep-rebuild (the browser binary now explicitly links with Kerberos libraries instead of using dlopen, and it uses system headers instead of some modified bundled copy; this way breakages should be fixable by revdep-rebuild and not silent).
If you're interested in testing, please emerge that version with USE="kerberos" and see if the Kerberos support works as intended. It'd also be nice to test with various Kerberos implementations (MIT vs Heimdal).
Even if you're not using Kerberos, if something is broken in that version please also file bugs.
The changes implemented in that version should make it work better with revdep-rebuild (the browser binary now explicitly links with Kerberos libraries instead of using dlopen, and it uses system headers instead of some modified bundled copy; this way breakages should be fixable by revdep-rebuild and not silent).
August 27, 2011
www-client/chromium: experimental support for ChromeDriver
Due to popular demand, I've added experimental support for ChromeDriver to the latest dev channel release of www-client/chromium. It is controlled by USE="chromedriver".
Please report any issues, even minor ones, with this flag. This should work "out of the box", without any additional downloads or setup. If it doesn't, I'd like to fix it.
By the way, that dev channel release also has optional support for PulseAudio. It is controlled by USE="pulseaudio".
And there are only 4 open bug reports assigned to the Gentoo Chromium Team!
Please report any issues, even minor ones, with this flag. This should work "out of the box", without any additional downloads or setup. If it doesn't, I'd like to fix it.
By the way, that dev channel release also has optional support for PulseAudio. It is controlled by USE="pulseaudio".
And there are only 4 open bug reports assigned to the Gentoo Chromium Team!
August 10, 2011
How to file a good bug about FTP-related bugs in Chrome
I have just done a little clean-up of the bugtracker and closed old FTP bugs which don't have enough information to fix them. Of course those bugs can still be re-opened after reporters respond on them.
One of the most important rules for bugs is: please submit information you're asked to submit. If you're unable to follow-up, it's very likely your problem can't be fixed because of missing info.
Generally when filing an FTP-related bug, you should provide:
Furthermore, if the FTP site is not public, just the URL or description is usually not enough to fix any problem. What's needed is either:
Finally, when submitting the raw directory listing, please don't just copy-paste it, because that results in implicit character set conversions. Use the browser's "Save As" command to save the raw listing to disk, and then attach that file to your bug report.
One of the most important rules for bugs is: please submit information you're asked to submit. If you're unable to follow-up, it's very likely your problem can't be fixed because of missing info.
Generally when filing an FTP-related bug, you should provide:
- version number of Chrome
- URL that causes the problem
- detailed description of the issue (steps to reproduce, expected result, actual result, etc).
Furthermore, if the FTP site is not public, just the URL or description is usually not enough to fix any problem. What's needed is either:
- raw directory listing (if you see anything like that in the error message, it should be obvious what to do), or
- Wireshark/other sniffer's dump of network traffic.
Finally, when submitting the raw directory listing, please don't just copy-paste it, because that results in implicit character set conversions. Use the browser's "Save As" command to save the raw listing to disk, and then attach that file to your bug report.
August 6, 2011
www-client/chromium-14.0.835.15 dev channel release
Last dev channel release of www-client/chromium was really non-trivial to package. Here are the bugs that I had to fix:
- bug #375759 by Mathieu Zhang
- bug #375827 by fkhp
- bug #376301 by Julien Sanchez
- bug #376499 and bug #376501 by Mike Gilbert
- NaCl didn't work (missing IRT in the tarballs)
- system libvpx didn't work, had to switch back to bundled one
- WebRTC requires PulseAudio to compile
Now before you start worrying about PulseAudio (which I know many people don't want on their systems), let me remind you that this is still a hard masked ebuild, and I'll ensure that our dependency on PulseAudio becomes optional. I'm working closely with the upstream to make that possible, so please stay tuned. Feel free to add yourself to the CC list of bug #377847.
Enjoy your updates!
Subscribe to:
Posts (Atom)