Bug#169361: ITP: apt-listbugs -- Retrieves bugs from BTS and lists them
Package: wnpp Version: unavailable; reported 2002-11-17 Severity: wishlist * Package name: apt-listbugs * License : GPL Description : Retrieves bugs from BTS and lists them Hi, I'm writing a tool 'apt-listbugs' which retrieves bugs from the Debian Bug Tracking System and lists them. Especially, apt-listbugs is invoked before each installation by apt in order to check whether the upgrade is safe. If it finds critical bugs, you can stop the installation and save your system. This package should be useful for developers and/or users of sid. Of cource, it's needed that anyone reports the critical bug to BTS to save our own system :) -- System Information: Debian Release: testing/unstable Architecture: i386 Kernel: Linux vass 2.4.19-686 #1 Sun Oct 6 18:37:38 EST 2002 i686 Locale: LANG=ja_JP.eucJP, LC_CTYPE=ja_JP.eucJP
Bug#169361: ITP: apt-listbugs -- Retrieves bugs from BTS and lists them
On Sun, Nov 17, 2002 at 01:44:43AM +0900, Masato Taruishi wrote: > Hi, I'm writing a tool 'apt-listbugs' which retrieves bugs from > the Debian Bug Tracking System and lists them. Especially, > apt-listbugs is invoked before each installation by apt > in order to check whether the upgrade is safe. If it finds > critical bugs, you can stop the installation and save your > system. This package should be useful for developers and/or > users of sid. > > Of cource, it's needed that anyone reports the critical bug > to BTS to save our own system :) At what phase of the upgrade will this tool run? How will it determine whether the bug actually applies to the version of the package being installed? Or will it rely on the user's manual review to approve every package? -- - mdz
Bug#169361: ITP: apt-listbugs -- Retrieves bugs from BTS and lists them
At Sat, 16 Nov 2002 13:00:20 -0500, Matt Zimmerman wrote: > > Hi, I'm writing a tool 'apt-listbugs' which retrieves bugs from > > the Debian Bug Tracking System and lists them. Especially, > > apt-listbugs is invoked before each installation by apt > > in order to check whether the upgrade is safe. If it finds > > critical bugs, you can stop the installation and save your > > system. This package should be useful for developers and/or > > users of sid. > > > > Of cource, it's needed that anyone reports the critical bug > > to BTS to save our own system :) > > At what phase of the upgrade will this tool run? At DPkg::Pre-Install-Pkgs. The following logs are of current apt-listbugs. % sudo apt-get install libstdc++2.10-glibc2.2 Reading Package Lists... Done Building Dependency Tree... Done 1 packages upgraded, 0 newly installed, 0 to remove and 0 not upgraded. Need to get 0B/130kB of archives. After unpacking 16.4kB will be freed. Critical bugs of libstdc++2.10-glibc2.2 (#169065) error while loading shared libraries: libstdc++-libc6.2-2.so.3: cannot open shared object file: No such file or directory (#169063) libstdc++-libc6.2-2.so.3 missing or not symlinked properly (#169061) Must rename /usr/lib/libstdc++libc6.2-2.so.3 to /usr/lib/libstdc++-libc6.2-2.so.3 (#169060) Possible misnaming of symlink for library name. (#169059) Bad symbolic link to libstdc++-3libc6.2-2-2.10.0.so (#169042) Upgrading libstdc++ breaks lots of stuff (#160977) suck: Broken handling of per-host configuration with the option -AL Grave bugs of libstdc++2.10-glibc2.2 (#169072) base: typo in library-dependencies for glibc Are you sure to install/upgrade these packages? [Y/n] n E: Sub-process /usr/sbin/apt-listbugs --apt -c returned an error code (1) E: Failure running script /usr/sbin/apt-listbugs --apt -c According to BTS (currently it needs to use other programs like querybts), these bugs are fixed in 1:2.95.4-15. vass% LANG=C sudo apt-get install libstdc++2.10-glibc2.2=1:2.95.4-15 Reading Package Lists... Done Building Dependency Tree... Done 1 packages upgraded, 0 newly installed, 0 to remove and 0 not upgraded. Need to get 0B/130kB of archives. After unpacking 16.4kB will be freed. Critical bugs of libstdc++2.10-glibc2.2 (#169065) error while loading shared libraries: libstdc++-libc6.2-2.so.3: cannot open shared object file: No such file or directory (#169063) libstdc++-libc6.2-2.so.3 missing or not symlinked properly (#169061) Must rename /usr/lib/libstdc++libc6.2-2.so.3 to /usr/lib/libstdc++-libc6.2-2.so.3 (#169060) Possible misnaming of symlink for library name. (#169059) Bad symbolic link to libstdc++-3libc6.2-2-2.10.0.so (#169042) Upgrading libstdc++ breaks lots of stuff (#160977) suck: Broken handling of per-host configuration with the option -AL Grave bugs of libstdc++2.10-glibc2.2 (#169072) base: typo in library-dependencies for glibc Are you sure to install/upgrade these packages? [Y/n] (Reading database ... 55925 files and directories currently installed.) Preparing to replace libstdc++2.10-glibc2.2 1:2.95.4-12 (using .../libstdc++2.10-glibc2.2_1%3a2.95.4-15_i386.deb) ... Unpacking replacement libstdc++2.10-glibc2.2 ... Setting up libstdc++2.10-glibc2.2 (2.95.4-15) ... Once I upgrade the package, some bugs are no longer displayed. vass% sudo apt-get --reinstall install libstdc++2.10-glibc2.2 Reading Package Lists... Done Building Dependency Tree... Done 0 packages upgraded, 0 newly installed, 1 reinstalled, 0 to remove and 0 not upgraded. Need to get 0B/130kB of archives. After unpacking 0B will be used. Do you want to continue? [Y/n] Critical bugs of libstdc++2.10-glibc2.2 (#169042) Upgrading libstdc++ breaks lots of stuff (#160977) suck: Broken handling of per-host configuration with the option -AL Grave bugs of libstdc++2.10-glibc2.2 (#169072) base: typo in library-dependencies for glibc Are you sure to install/upgrade these packages? [Y/n] > How will it determine whether the bug actually applies to the version of the > package being installed? Or will it rely on the user's manual review to > approve every package? apt-listbugs does a non-accurate analysis to determine that the bug applies to the version. This tool is expected to save many machines from broken packages and not to flood many bug reports which is the same bug as many as possible. In upgrade phase, the following situations are under considerations: submit current new -> In above situation, you have already gotten the bug -> not care. (submit means the version where the bug has been submitted) You can select whether apt-listbugs list it or not. It doesn't list it by default. currentnew submit ---> In above situaion, the new package maybe doesn't have the bug yet. You can select whether apt-listbugs list it or not. It doesn't list it by default. current submit new
Bug#169361: ITP: apt-listbugs -- Retrieves bugs from BTS and lists them
On Sun, Nov 17, 2002 at 06:46:26AM +0900, Masato Taruishi wrote: > According to BTS (currently it needs to use other programs like querybts), > these bugs are fixed in 1:2.95.4-15. But does apt-listbugs attempt to determine this information automatically? If so, how? I do not see how this information can be accurately obtained from the current BTS. > Once I upgrade the package, some bugs are no longer displayed. > > vass% sudo apt-get --reinstall install libstdc++2.10-glibc2.2 > Reading Package Lists... Done > Building Dependency Tree... Done > 0 packages upgraded, 0 newly installed, 1 reinstalled, 0 to remove and 0 not > upgraded. > Need to get 0B/130kB of archives. After unpacking 0B will be used. > Do you want to continue? [Y/n] > Critical bugs of libstdc++2.10-glibc2.2 > (#169042) Upgrading libstdc++ breaks lots of stuff > (#160977) suck: Broken handling of per-host configuration with the option -AL > Grave bugs of libstdc++2.10-glibc2.2 > (#169072) base: typo in library-dependencies for glibc > Are you sure to install/upgrade these packages? [Y/n] What is different about these bugs, vis a vis the others that are no longer displayed?Indeed, two of these are duplicates of the bugs which were shown in the previous run. > > How will it determine whether the bug actually applies to the version of the > > package being installed? Or will it rely on the user's manual review to > > approve every package? > > apt-listbugs does a non-accurate analysis to determine that the bug applies > to the version. This tool is expected to save many machines from broken > packages and not to flood many bug reports which is the same bug as many as > possible. > > In upgrade phase, the following situations are under considerations: > > submit current new > -> > > In above situation, you have already gotten the bug -> not care. > (submit means the version where the bug has been submitted) > You can select whether apt-listbugs list it or not. It doesn't > list it by default. > > currentnew submit > ---> > > In above situaion, the new package maybe doesn't have the bug yet. > You can select whether apt-listbugs list it or not. It doesn't list > it by default. > > current submit new > ---> > > In above situation, the new package may have the bug (it may be > fixed and still archived in BTS). > Currently apt-listbugs lists it. This is not entirely clear, but it sounds like you are comparing the (optional) Version: header in the original BTS report against the package version. Is this what you are doing? > I guess the above simple algorithm can probe most of critical (I mean this > is not a term of serverity) bugs. apt-listbugs isn't a tool that lists > accurate bugs that actually apply to the version, but that warns that the > version may have critical bugs. At least it's useful for me. This is an interesting idea, though it involves a lot of guesswork with the data that is available. Is it significantly better than simply listing the open RC bugs for the packages? -- - mdz
Bug#169361: ITP: apt-listbugs -- Retrieves bugs from BTS and lists them
At Sat, 16 Nov 2002 17:49:22 -0500, Matt Zimmerman wrote: > > Once I upgrade the package, some bugs are no longer displayed. > > > > vass% sudo apt-get --reinstall install libstdc++2.10-glibc2.2 > > Reading Package Lists... Done > > Building Dependency Tree... Done > > 0 packages upgraded, 0 newly installed, 1 reinstalled, 0 to remove and 0 > > not upgraded. > > Need to get 0B/130kB of archives. After unpacking 0B will be used. > > Do you want to continue? [Y/n] > > Critical bugs of libstdc++2.10-glibc2.2 > > (#169042) Upgrading libstdc++ breaks lots of stuff > > (#160977) suck: Broken handling of per-host configuration with the option > > -AL > > Grave bugs of libstdc++2.10-glibc2.2 > > (#169072) base: typo in library-dependencies for glibc > > Are you sure to install/upgrade these packages? [Y/n] > > What is different about these bugs, vis a vis the others that are no longer > displayed?Indeed, two of these are duplicates of the bugs which were > shown in the previous run. These bugs are displayed because apt-listbugs can't determine what version the bug is assigned (No 'optional' Version: header is found, or the bug is reassinged from other packages etc.) > > > How will it determine whether the bug actually applies to the version of > > > the > > > package being installed? Or will it rely on the user's manual review to > > > approve every package? > > > > apt-listbugs does a non-accurate analysis to determine that the bug applies > > to the version. This tool is expected to save many machines from broken > > packages and not to flood many bug reports which is the same bug as many as > > possible. > > > > In upgrade phase, the following situations are under considerations: > > > > submit current new > > -> > > > > In above situation, you have already gotten the bug -> not care. > > (submit means the version where the bug has been submitted) > > You can select whether apt-listbugs list it or not. It doesn't > > list it by default. > > > > currentnew submit > > ---> > > > > In above situaion, the new package maybe doesn't have the bug yet. > > You can select whether apt-listbugs list it or not. It doesn't list > > it by default. > > > > current submit new > > ---> > > > > In above situation, the new package may have the bug (it may be > > fixed and still archived in BTS). > > Currently apt-listbugs lists it. > > This is not entirely clear, but it sounds like you are comparing the > (optional) Version: header in the original BTS report against the package > version. Is this what you are doing? Yes, it's optional. So the above bugs are displayed. Is there another solution to compare? I want to adapt it. > > I guess the above simple algorithm can probe most of critical (I mean this > > is not a term of serverity) bugs. apt-listbugs isn't a tool that lists > > accurate bugs that actually apply to the version, but that warns that the > > version may have critical bugs. At least it's useful for me. > > This is an interesting idea, though it involves a lot of guesswork with the > data that is available. Is it significantly better than simply listing the > open RC bugs for the packages? Hmm, do you have a tool to simply list the open RC bugs before the upgrade? Basically apt-listbugs is similar as such tools, it simply and only listed RC bugs before. But one problem is that the information of 'open RC bugs' is for the latest packages. The version may not be mirrored to your mirror site yet. That's just what I faced :( So it now optionally does more guesswork.
Bug#169361: ITP: apt-listbugs -- Retrieves bugs from BTS and lists them
At Sat, 16 Nov 2002 17:49:22 -0500, Matt Zimmerman wrote: > > According to BTS (currently it needs to use other programs like querybts), > > these bugs are fixed in 1:2.95.4-15. > > But does apt-listbugs attempt to determine this information automatically? > If so, how? I do not see how this information can be accurately obtained > from the current BTS. I also don't see. So this needs a manual diagnostics.
Bug#169361: ITP: apt-listbugs -- Retrieves bugs from BTS and lists them
I've uploaded test version of the tool at deb http://people.debian.org/~taru/deb/apt-listbugs/ ./ I'd like you to check it. Currently, it retrieves bugs from not bugs.debian.org, but hanzubon.debian.gr.jp, which does proxy-caching of bugs.debian.org temporally. This keeps a query to bugs.debian.org for 20 miniutes to avoid many queries to it. I guess we need more sophisticated framework. At Sun, 17 Nov 2002 01:44:43 +0900, Masato Taruishi wrote: > * Package name: apt-listbugs > * License : GPL > Description : Retrieves bugs from BTS and lists them > > Hi, I'm writing a tool 'apt-listbugs' which retrieves bugs from > the Debian Bug Tracking System and lists them. Especially, > apt-listbugs is invoked before each installation by apt > in order to check whether the upgrade is safe. If it finds > critical bugs, you can stop the installation and save your > system. This package should be useful for developers and/or > users of sid. > > Of cource, it's needed that anyone reports the critical bug > to BTS to save our own system :) > > -- System Information: > Debian Release: testing/unstable > Architecture: i386 > Kernel: Linux vass 2.4.19-686 #1 Sun Oct 6 18:37:38 EST 2002 i686 > Locale: LANG=ja_JP.eucJP, LC_CTYPE=ja_JP.eucJP
