Bug#1004879: acpitool: New upstream development?
On 02 Feb 2022 22:25, Guillem Jover wrote: > Source: acpitool > Source-Version: 0.5.1-6 > Severity: wishlist > Tags: upstream > X-Debbugs-Cc: Al Stone > > Hi! > > I just noticed that Al Stone forked the upstream of this project > at <https://pagure.io/acpitool>, collected several of the distro > patches and prepared a 0.5.2 release. Although no more activity > happened since 3 years ago, so I'm not sure what the current status > is there. I'm CCing Al to try to clarify whether this is abandoned > or in maintenance mode, and further patches and similar would be > accepted (we have some in the Debian Bug Tracking System). Which > means we could switch to use that as our upstream. > > Thanks, > Guillem I resigned from Debian some time ago. Do with this whatever you'd like. I am no longer willing to volunteer my time to this distro. -- ciao, al
Bug#985233: O: lmbench -- Utilities to benchmark UNIX systems
On 22 Mar 2021 22:37, Andreas Beckmann wrote: > Hi Al, > > On Sun, 14 Mar 2021 15:17:52 -0600 Al Stone wrote: > > I intend to orphan the lmbench package. I no longer use it, > > Can you push the changes and tag from the -5 upload, please? > > And could you try to move the package on salsa from your personal namespace > to the 'debian' or 'hpc-team' namespace? (I think that should be Settings -> > General -> Advanced -> Transfer project, but I have never used it.) There is > no need to do an upload to update the Vcs URLs. > > Thanks, > > Andreas, who might adopt it for the HPC team Howdy, Andreas. I tried to transfer the package but the only namespace I was able to enter was my own. I can't tell if that's the way the other namespaces are set up or just operator error on my part -- either way, salsa won't let me. Sorry :(. -- Ciao, al ------ Al Stone E-mail: a...@ahs3.net --
Bug#985679: O: gnucobol -- COBOL compiler
Package: wnpp Severity: normal Control: affects -1 src:gnucobol I am orphaning the gnucobol package. The package description is: GnuCOBOL (formerly OpenCOBOL) is a free, modern COBOL compiler. GnuCOBOL implements a substantial part of the COBOL 85, COBOL 2002 and COBOL 2014 standards and X/Open COBOL, as well as many extensions included in other COBOL compilers (IBM COBOL, MicroFocus COBOL, ACUCOBOL-GT and others). . GnuCOBOL translates COBOL into C and compiles the translated code using a native C compiler. . Build COBOL programs on various platforms, including GNU/Linux, Unix, Mac OS X, and Microsoft Windows. GnuCOBOL has also been built on HP/UX, z/OS, SPARC, RS6000, AS/400, along with other combinations of machines and operating systems. . While being held to a high level of quality and robustness, GnuCOBOL does not claim to be a “Standard Conforming” implementation of COBOL. . GnuCOBOL passes over 9600 of the NIST COBOL 85 test suite tests and over 750 internal checks during build.
Bug#985678: O: rasdaemon -- utility to receive RAS error tracings
Package: wnpp Severity: normal Control: affects -1 src:rasdaemon I orphaning the rasdaemon package. The package description is: rasdaemon is a RAS (Reliability, Availability and Serviceability) logging tool. It currently records memory errors, using the EDAC tracing events. EDAC are drivers in the Linux kernel that handle detection of ECC errors from memory controllers for most chipsets on x86 and ARM architectures. This userspace component consists of an init script which makes sure EDAC drivers and DIMM labels are loaded at system startup, as well as a utility for reporting current error counts from the EDAC sysfs files.
Bug#985677: O: acpica-unix -- ACPICA tools for the development and debug of ACPI tables
Package: wnpp Severity: normal Control: affects -1 src:acpica-unix I am orphaning the acpica-unix package. The package description is: The ACPI Component Architecture (ACPICA) project provides an OS-independent reference implementation of the Advanced Configuration and Power Interface Specification (ACPI). ACPICA code contains those portions of ACPI meant to be directly integrated into the host OS as a kernel-resident subsystem, and a small set of tools to assist in developing and debugging ACPI tables. . This package contains only the user-space tools needed for ACPI table development, not the kernel implementation of ACPI. The following commands are installed: -- iasl: compiles ASL (ACPI Source Language) into AML (ACPI Machine Language), suitable for inclusion as a DSDT in system firmware. It also can disassemble AML, for debugging purposes. -- acpibin: performs basic operations on binary AML files (e.g., comparison, data extraction) -- acpidump: write out the current contents of ACPI tables -- acpiexec: simulate AML execution in order to debug method definitions -- acpihelp: display help messages describing ASL keywords and op-codes -- acpinames: display complete ACPI name space from input AML -- acpisrc: manipulate the ACPICA source tree and format source files for specific environments -- acpixtract: extract binary ACPI tables from acpidump output (see also the pmtools package)
Bug#985557: RM: gnucobol -- ROM; wrong version of compiler, breaks compatibility
On 21 Mar 2021 20:50, Adrian Bunk wrote: > On Sun, Mar 21, 2021 at 11:31:45AM -0600, Al Stone wrote: > > On 21 Mar 2021 14:20, Adrian Bunk wrote: > > > On Sat, Mar 20, 2021 at 11:06:01AM -0600, Al Stone wrote: > > > > On 20 Mar 2021 00:09, Ivo De Decker wrote: > > > > > Control: tags -1 moreinfo > > > > > > > > > > Hi, > > > > > > > > > > On Fri, Mar 19, 2021 at 04:25:01PM -0600, Al Stone wrote: > > > > > > Please remove the version of gnucobol in unstable. Per upstream, > > > > > > this version in not backwards compatible with any prior version. > > > > > > I made a mistake in packaging it at all. > > > > > > > > > > > > An upload of the proper version (3.1.2) is being prepared. > > > > > > > > > > Removing a package from unstable and then uploading the same package > > > > > with a > > > > > lower version isn't possible. If you want to go back to version 3.x, > > > > > you'll > > > > > need to do an upload with a version higher than the current one. > > > > > > > > > > Cheers, > > > > > > > > > > Ivo > > > > > > > > Understood. My only option may be to increase the epoch. > > > > > > An epoch is not the only option, and it is the wrong option: > > > https://www.debian.org/doc/debian-policy/ch-controlfields.html#epochs-should-be-used-sparingly > > > > Why are you assuming I have not read the documentation? ... > > You wrote "My only option", which implied to me that you were not aware > of the other option that is actually the recommended option. > > > Or that I do not know that that particular bit of Policy > > does not exist? That is precisely why the word "may" > > was used. > > I'm really getting tired of these sorts of assumptions > that everyone is a native English speaker. > > I am not. > > My understanding of "only" is that it means "there is not any other". > > Fancy interactions between the words "only" and "may" are beyond my > knowledge of the English language. Yet another assumption. I taught English as a second language. I speak at least two others. I am very aware of the strangeness of the English language and write intentionally simple English. I deal with this on a daily basis with colleagues from multiple countries. > > I'm really getting tired of these sorts of assumptions. > > It would be much more useful to assume good intent on > > the part of others. > > This is an impossible proposition when it comes across as if the other > person is about to make an irreversible mistake, like adding an epoch > without first getting consensus on debian-devel. No, it is not impossible. You see it as impossible. I do not. And, this highlights the problem: you are assuming I do not know about the need for consensus. You have no idea what I'm planning to do next, and you have no idea what I do and do not know. Yet, you assume I am going to make a mistake. All I'm asking is that you find a way to do as many others do -- assume that people know what they are doing until proven otherwise. > cu > Adrian > -- Ciao, al -- Al Stone Debian Developer E-mail: a...@ahs3.nethttp://www.debian.org a...@debian.org --
Bug#985557: RM: gnucobol -- ROM; wrong version of compiler, breaks compatibility
On 20 Mar 2021 00:09, Ivo De Decker wrote: > Control: tags -1 moreinfo > > Hi, > > On Fri, Mar 19, 2021 at 04:25:01PM -0600, Al Stone wrote: > > Please remove the version of gnucobol in unstable. Per upstream, > > this version in not backwards compatible with any prior version. > > I made a mistake in packaging it at all. > > > > An upload of the proper version (3.1.2) is being prepared. > > Removing a package from unstable and then uploading the same package with a > lower version isn't possible. If you want to go back to version 3.x, you'll > need to do an upload with a version higher than the current one. > > Cheers, > > Ivo Understood. My only option may be to increase the epoch. -- Ciao, al ------ Al Stone Debian Developer E-mail: a...@ahs3.nethttp://www.debian.org a...@debian.org --
Bug#985557: RM: gnucobol -- ROM; wrong version of compiler, breaks compatibility
Package: ftp.debian.org Severity: normal Please remove the version of gnucobol in unstable. Per upstream, this version in not backwards compatible with any prior version. I made a mistake in packaging it at all. An upload of the proper version (3.1.2) is being prepared.
Bug#985409: RM: gnucobol/4.0~early~20200606-3
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: rm ROM: the wrong upstream version was packaged; I made a mistake. This version completely breaks any backwards compatibility and should not have been used. It is not recommended by upstream because it breaks compatibility. If this version of the package stays in Debian at all, it should be in experimental, at best.
Bug#985233: O: lmbench -- Utilities to benchmark UNIX systems
Package: wnpp Severity: normal X-Debbugs-Cc: da...@debian.org Control: affects -1 src:lmbench I intend to orphan the lmbench package. I no longer use it, and have not for quite some time, and no longer have the time to maintain it properly. Upstream seems to be static (perhaps reasonably so for a benchmark) but we have cleaned up things a bit over the years. Cleaned up most of the lintian issues on the last update, too, but there are still a couple of minor bugs left. The package description is: Lmbench is a set of utilities to test the performance of a unix system producing detailed results as well as providing tools to process them. It includes a series of micro benchmarks that measure some basic operating system and hardware metrics: . * file reading and summing * memory bandwidth while reading, writing and copying * copying data through pipes * copying data through Unix sockets * reading data through TCP/IP sockets
Bug#985165: O: python-jenkinsapi -- bindings for Python usage of the Jenkins remote API
Package: wnpp Severity: normal Control: affects -1 src:python-jenkinsapi I intend to orphan the python-jenkinsapi package. I no longer use it nor have a need for it; hopefully, someone else does. The package description is: Jenkins is the market leading continuous integration system, originally created by Kohsuke Kawaguchi. This API makes Jenkins even easier to use by providing an easy to use conventional Python interface. . Jenkins (and its predecessor Hudson) are useful projects for automating common development tasks (e.g., unit-testing, production batches) - but they are somewhat Java-centric. Thankfully the designers have provided an excellent and complete REST interface. This library wraps up that interface as more conventional Python objects in order to make most Jenkins-oriented tasks simpler.
Bug#748783: need another packager, if there is interest
I thought I would have time to package this but clearly I do not. Moving this back to RFP in case someone is interested. -- Ciao, al -- Al Stone Debian Developer E-mail: a...@ahs3.nethttp://www.debian.org a...@debian.org --
Bug#966680: src:acpica-unix: fails to migrate to testing for too long: FTBFS on s390x
On 24 Sep 2020 11:23, Paul Gevers wrote: > Hi Al, > > ping > > On Sat, 1 Aug 2020 21:34:14 +0200 Paul Gevers wrote: > > This bug will trigger auto-removal when appropriate. As with all new > > bugs, there will be at least 30 days before the package is auto-removed. > > acpica-unix is a key package and will not be autoremoved. Can you please > fix the situation? > > Paul Yup, working on it. I may have to turn off s390x support for the short term; the issue is that this package is solely little-endian upstream and it has been patched and bodged so many times for big-endian support, it has been become unmaintainable for big- endian. These patches are being re-done and made straightforward but it is taking a lot longer than hoped; ideally, I can get them upstreamed and simplify further. -- Ciao, al ------ Al Stone Debian Developer E-mail: a...@ahs3.nethttp://www.debian.org a...@debian.org -- signature.asc Description: PGP signature
Bug#966099: gnucobol: install gnucobol 3.1-rc1 by default instead of unstable version
Package: gnucobol Version: 4.0~early~20200606-3 Severity: normal Dear Maintainer, This version of the compiler unfortunately requires a recompile of all COBOL modules in order to be used. Further, this is still considered pretty unstable and upstream does not recommend it for daily use. Please revert the default version of the compiler to 3.1-rc1, the current stable version. Any of the 4.0+ versions should be in a separate package so as not to disturb stable development environments. -- System Information: Debian Release: bullseye/sid APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'unstable'), (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 5.7.0-1-amd64 (SMP w/8 CPU threads) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages gnucobol depends on: ii gcc 4:9.2.1-3.1 ii libc6 2.30-8 ii libcob5 4.0~early~20200606-3 ii libcob5-dev 4.0~early~20200606-3 ii libgmp-dev2:6.2.0+dfsg-6 ii libncurses-dev [libncurses5-dev] 6.2-1 ii libncurses5-dev 6.2-1 gnucobol recommends no packages. gnucobol suggests no packages. -- no debconf information
Bug#962081: gnucobol: Failing autopkgtest scripts should report what went wrong
On 05 Jun 2020 19:02, Petter Reinholdtsen wrote: > > I discovered what the problem is. The test [ $res ] do not work the way > you want it to. It need to compare with 0, like this: Which is kind of strange, and makes autopkgtest very hard to use since this works fine when run locally like so: # cd # autopkgtest -- null Everything passes when run this way. Easy fix now that you've pointed it out, but passing strange. > diff --git a/debian/tests/test01 b/debian/tests/test01 > index 1c0d63f..73e1fac 100755 > --- a/debian/tests/test01 > +++ b/debian/tests/test01 > @@ -1,4 +1,5 @@ > #!/bin/sh > + > cd debian/tests > > echo "info: compiling" > @@ -7,7 +8,7 @@ echo "info: compiling" > echo "info: running" > cmp -s test01.exp $AUTOPKGTEST_TMP/test01.act > res=$? > -if [ $res ] ; then > +if [ 0 = $res ] ; then > echo "success: test01 produced proper results" > else > echo "error: test01 did not produce proper results" > diff --git a/debian/tests/test02 b/debian/tests/test02 > index fb85d2e..cb4359d 100755 > --- a/debian/tests/test02 > +++ b/debian/tests/test02 > @@ -7,7 +7,7 @@ echo "info: compiling" > echo "info: running" > cmp -s test02.exp $AUTOPKGTEST_TMP/test02.act > res=$? > -if [ $res ] ; then > +if [ 0 == $res ] ; then > echo "success: test02 produced proper results" > else > echo "error: test02 did not produce proper results" > diff --git a/debian/tests/test03 b/debian/tests/test03 > index c028d8b..07d679c 100755 > --- a/debian/tests/test03 > +++ b/debian/tests/test03 > @@ -7,7 +7,7 @@ echo "info: compiling" > echo "info: running" > cmp -s test03.exp $AUTOPKGTEST_TMP/test03.act > res=$? > -if [ $res ] ; then > +if [ 0 == $res ] ; then > echo "success: test03 produced proper results" > else > echo "error: test03 did not produce proper results" > diff --git a/debian/tests/test04 b/debian/tests/test04 > index fd2a6ad..ee31d4a 100755 > --- a/debian/tests/test04 > +++ b/debian/tests/test04 > @@ -7,7 +7,7 @@ echo "info: compiling" > echo "info: running" > cmp -s test04.exp t$AUTOPKGTEST_TMP/est04.act > res=$? > -if [ $res ] ; then > +if [ 0 == $res ] ; then > echo "success: test04 produced proper results" > else > echo "error: test04 did not produce proper results" > > -- > Happy hacking > Petter Reinholdtsen > -- Ciao, al -- Al Stone Debian Developer E-mail: a...@ahs3.nethttp://www.debian.org a...@debian.org --
Bug#962081: gnucobol: Failing autopkgtest scripts should report what went wrong
On 03 Jun 2020 14:30, Petter Reinholdtsen wrote: > > Could > https://people.debian.org/~mpitt/autopkgtest/README.package-tests.html > > contain the key to why these test are failing? It states > > "The cwd of each test is guaranteed to be the root of the source > package, which will have been unpacked but not built. However note > that the tests must test the installed version of the program. Tests > may not modify the source tree (and may not have write access to it)." Hrm. So write access seems to be more constrained than this led me to believe; I'll try these patches out and rebuild tonight. I did think about using AUTOPKGTEST_TMP but had not convinced myself it was absolutely required. Thank you for all the help, Petter! > If so, the following patch might help: > > diff --git a/debian/tests/hello b/debian/tests/hello > index 60943be..15c3985 100755 > --- a/debian/tests/hello > +++ b/debian/tests/hello > @@ -1,4 +1,5 @@ > #!/bin/sh > +cd $AUTOPKGTEST_TMP > cat > HELLO.cob< HELLO * HISTORIC EXAMPLE OF HELLO WORLD IN COBOL > IDENTIFICATION DIVISION. > diff --git a/debian/tests/test01 b/debian/tests/test01 > index 22d943e..783901b 100755 > --- a/debian/tests/test01 > +++ b/debian/tests/test01 > @@ -2,10 +2,10 @@ > cd debian/tests > > echo "info: compiling" > -(cobc test01.cob > test01.act 2>&1) > +(cobc test01.cob > $AUTOPKGTEST_TMP/test01.act 2>&1) > > echo "info: running" > -cmp -s test01.exp test01.act > +cmp -s test01.exp $AUTOPKGTEST_TMP/test01.act > res=$? > if [ $res ] ; then > echo "success: test01 produced proper results" > diff --git a/debian/tests/test02 b/debian/tests/test02 > index 2e06f74..99f0978 100755 > --- a/debian/tests/test02 > +++ b/debian/tests/test02 > @@ -2,10 +2,10 @@ > cd debian/tests > > echo "info: compiling" > -(cobc test02.cob > test02.act 2>&1) > +(cobc test02.cob > $AUTOPKGTEST_TMP/test02.act 2>&1) > > echo "info: running" > -cmp -s test02.exp test02.act > +cmp -s test02.exp $AUTOPKGTEST_TMP/test02.act > res=$? > if [ $res ] ; then > echo "success: test02 produced proper results" > diff --git a/debian/tests/test03 b/debian/tests/test03 > index f378787..701ade9 100755 > --- a/debian/tests/test03 > +++ b/debian/tests/test03 > @@ -2,10 +2,10 @@ > cd debian/tests > > echo "info: compiling" > -(cobc test03.cob > test03.act 2>&1) > +(cobc test03.cob > $AUTOPKGTEST_TMP/test03.act 2>&1) > > echo "info: running" > -cmp -s test03.exp test03.act > +cmp -s test03.exp $AUTOPKGTEST_TMP/test03.act > res=$? > if [ $res ] ; then > echo "success: test03 produced proper results" > diff --git a/debian/tests/test04 b/debian/tests/test04 > index 04b325e..c50b157 100755 > --- a/debian/tests/test04 > +++ b/debian/tests/test04 > @@ -2,10 +2,10 @@ > cd debian/tests > > echo "info: compiling" > -(cobc test04.cob > test04.act 2>&1) > +(cobc test04.cob > $AUTOPKGTEST_TMP/test04.act 2>&1) > > echo "info: running" > -cmp -s test04.exp test04.act > +cmp -s test04.exp t$AUTOPKGTEST_TMP/est04.act > res=$? > if [ $res ] ; then > echo "success: test04 produced proper results" > > -- > Happy hacking > Petter Reinholdtsen > -- Ciao, al -- Al Stone Debian Developer E-mail: a...@ahs3.nethttp://www.debian.org a...@debian.org --
Bug#959120: O: libbrahe -- heterogeneous C library of numeric functions
Package: wnpp Severity: normal I intend to orphan the libbrahe package. I no longer have an interest and upstream seems to have slowed to a halt, if not abandoned it. The package description is: This library provides: . * a function for rounding floating point values to a specific number of digits * several pseudo-random number generators, including the Mersenne Twister, various algorithms by Marsaglia, and ISAAC * least common multiple and greatest common denominator functions * a few trigonometry functions for finding the inversions of hyperbolic sine, cosine, and tangent . This library is also used by libevocosm, which is in turn the foundation for Acovea, used to determine optimal compiler optimizations
Bug#945816: O: gnucobol -- COBOL compiler
On 21 Apr 2020 08:23, Petter Reinholdtsen wrote: > [Ludwin Janvier] > > I intend to orphan the gnucobol package. > > Hi. I really enjoyed finding GNU Cobol in Debian, and hope it will stay > here for a long time. Unfortunately I do not have the capacity to > maintain it myself in Debian. > > Can you tell something about the problems with maintaining this package, > or what a future maintainer should keep in mind? > > I visited what I believe is the official IRC channel for the project, > irc://irc.oftc.net/#gnucobol, and there were no-one there, which I found > worrying. > -- > Happy hacking > Petter Reinholdtsen For somewhat nostalgic reasons on my part, I'm looking at this package and thinking about adopting it. It looks like the package has not been touched in some time, but upstream still seems to be active (commits within the last day, for example). Petter, if you'd rather adopt it, let me know. Otherwise, assuming it is in reasonably decent shape to start with, which it seems to be, I'll adopt it. -- Ciao, al ------ Al Stone Debian Developer E-mail: a...@ahs3.nethttp://www.debian.org a...@debian.org --
Bug#841238: acpidump: "turbostat" binary silently dropped?
Package: acpica-tools Followup-For: Bug #841238 I am closing this bug since turbostat has been moved to a different package. Please install linux-cpupower to install turbostat.
Bug#881001: Bug#884510: libevocosm: Build-Depends on libcoyotl-dev which is scheduled for removal
On 03/27/2018 02:01 PM, Jeremy Bicha wrote: >> the maintainer of libcoyotl has requested its removal: #881001, >> libevocosm is the only remaining user. > > Both packages have the same maintainer! > > Al, do you want libevocom removed from Debian too? > > Thanks, > Jeremy Bicha > Whups, forgot about that. Yes, or at least orphaned. Upstream is the same for both and development stopped quite some time ago. If someone is interested in maintaining these, please pick them up. -- Ciao, al ---------- Al Stone Debian Developer E-mail: a...@debian.org http://www.debian.org --
Bug#748783: uploaded to NEW queue
just an fyi: packages have been put in for NEW queue processing
Bug#881003: libunwind: Updating the libunwind Uploaders list
Source: libunwind Severity: minor Since I have not actively used or maintained this package in quite a long time, there is no need for me to be included as an Uploader; so, please remove "Al Stone <a...@debian.org>" from the Uploaders list. Thanks. -- System Information: Debian Release: buster/sid APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.13.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), LANGUAGE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system)
Bug#881001: RM: libcoyotl -- ROM; dead upstream, low popcnt
Package: ftp.debian.org Severity: normal There is no need to retain this package in the archives. There are very, very few users, and there is no upstream development ongoing or planned.
Bug#869589: libunwind: needs maintainer
On 07/24/2017 09:30 AM, Graham Inggs wrote: > Source: libunwind > Version: 1.1-4.1 > Severity: serious > X-Debbugs-CC: a...@debian.org > > Hi Al > > As per #863770 and #868643, Matthieu Delahaye and Daigo Moriwaki are no > longer maintaining libunwind. Al Stone, you are our only hope! You are > the last listed uploader for this package. If you intend stepping up as > the lone maintainer, please close this bug. > > Alternatively, I can orphan this package so that maintainers of the > packages that depend on it can become aware it needs attention, and > hopefully someone or some team will be interested enough to adopt it. > > Regards > Graham > Woof. I had not realized I was the only one left. Please orphan the package -- I really do not have time to maintain it and it's important enough it really needs someone who can pay attention to it. -- Ciao, al ------ Al Stone Debian Developer E-mail: a...@debian.org http://www.debian.org --
Bug#789804: libevocosm: please make the build reproducible
On 01/15/2017 11:14 PM, Chris Lamb wrote: >> Would you consider applying this patch and uploading? > > Friendly ping on this :) > > > Best wishes, > Thanks. I have not forgotten, just busy. -- Ciao, al ---------- Al Stone Debian Developer E-mail: a...@ahs3.nethttp://www.debian.org a...@debian.org --
Bug#731761: acpidump: "turbostat" binary silently dropped?
My apologies for not being very clear in the changelog. The transition could have been handled better. It turns out there are two versions of acpidump -- one in the Linux kernel source tree and one in the upstream ACPICA source that acpica-tools originally started from, both from the same upstream authors. Having discussed it with them, upstream wants to get to a single version of acpidump -- and that's why it appears there's a new version of the tool. AFAIK, both versions are pretty close to being in sync in terms of functionality. Turbostat is a slightly different problem. I will close this bug with a note in the changelog that turbostat can now be found in the package collectd-core, something that should have been mentioned much earlier, but I unfortunately did not. It was also dropped from acpica-tools because it is not part of the ACPICA upstream, but part of the Linux kernel tree. The acpica-tools package is now at least from a single source upstream, without the Debian user losing any functionality. Again, my apologies for the lack of info in the changelog. I've added info to it now that should help. -- Ciao, al -- Al Stone Debian Developer E-mail: a...@debian.org http://www.debian.org --
Bug#407708: iasl optimization generates a broken DSDT
>From what I can see in this bug report, the issue being reported is not a bug. Removing the External() reference mentioned is the clue. When iasl is decompiling a DSDT/SSDT, if there are external references in the AML, it needs to know about the argument list to the externally defined object to generate proper code. In very old versions of iasl, such as 20061109 mentioned here, this was not handled well at all, either in iasl, nor in AML. This has since been changed in the ACPI specification so that now iasl can capture the argument list info that it needs to work properly. However, that also means that iasl needs to be provided with *all* of the DSDTs/SSDTs that contain all of the definitions of the externals being referenced. If iasl does not have all of the definitions needed, it cannot decompile properly and ergo cannot recompile what it decompiled. In more recent versions of iasl, the issue is specifically called out if discovered. For example, on my laptop, a Lenovo t540s: $ iasl -d DSDT Intel ACPI Component Architecture ASL+ Optimizing Compiler version 20160108-64 Copyright (c) 2000 - 2016 Intel Corporation Input file DSDT, Length 0x10DFE (69118) bytes ACPI: DSDT 0x 010DFE (v01 LENOVO TP-GJ2280 INTL 20120711) Pass 1 parse of [DSDT] Pass 2 parse of [DSDT] Parsing Deferred Opcodes (Methods/Buffers/Packages/Regions) Parsing completed ACPI Error: External method arg count mismatch _SB_.PCI0.VID_.GLIS: Current 2, attempted 1 (20160108/dmextern-822) ACPI Error: External method arg count mismatch _SB_.PCI0.VID_.GLIS: Current 2, attempted 1 (20160108/dmextern-822) ACPI Error: External method arg count mismatch _SB_.PCI0.VID_.GLIS: Current 2, attempted 1 (20160108/dmextern-822) ACPI Error: External method arg count mismatch _SB_.PCI0.VID_.GLIS: Current 2, attempted 1 (20160108/dmextern-822) Found 8 external control methods, reparsing with new information Pass 1 parse of [DSDT] Pass 2 parse of [DSDT] Parsing Deferred Opcodes (Methods/Buffers/Packages/Regions) Parsing completed Disassembly completed ASL Output:DSDT.dsl - 559007 bytes iASL Warning: There were 8 external control methods found during disassembly, but additional ACPI tables to resolve these externals were not specified. The resulting disassembler output file may not compile because the disassembler did not know how many arguments to assign to these methods. To specify the tables needed to resolve external control method references, the -e option can be used to specify the filenames. Note: SSDTs can be dynamically loaded at runtime and may or may not be available via the host OS. Example iASL invocations: iasl -e ssdt1.aml ssdt2.aml ssdt3.aml -d dsdt.aml iasl -e dsdt.aml ssdt2.aml -d ssdt1.aml iasl -e ssdt*.aml -d dsdt.aml In addition, the -fe option can be used to specify a file containing control method external declarations with the associated method argument counts. Each line of the file must be of the form: External (, MethodObj, ) Invocation: iasl -fe refs.txt -d dsdt.aml -- Ciao, al -- Al Stone Debian Developer E-mail: a...@debian.org http://www.debian.org --
Bug#419687: acpidump: Ignores write errors
I think this bug has long ago been fixed, so I'm going to close this bug. Testing shows this: (laptop) touch doo (laptop) chmod a-w doo (laptop) ll doo -r--r--r-- 1 me me 0 Jan 30 16:46 doo (laptop) acpidump -o doo Target path already exists, overwrite? [y|n] n (laptop) echo $? 255 (laptop) acpidump -o doo Target path already exists, overwrite? [y|n] y Could not open file: Permission denied Could not open output file: doo I also tried this: (laptop) mkdir foo (laptop) chmod a-x foo (laptop) chmod a-w foo (laptop) acpidump -o foo/bar Could not open file: Permission denied Could not open output file: foo/bar Let me know if there's a case I missed somewhere. -- Ciao, al -- Al Stone Debian Developer E-mail: a...@debian.org http://www.debian.org --
Bug#799015: ITP: rasdaemon -- utility to receive RAS error messages
Package: wnpp Severity: wishlist Owner: Al Stone <a...@debian.org> * Package name: rasdaemon Version : 0.5.6 Upstream Author : Mauro Carvalho Chehab <mche...@infradead.org> * URL : https://apps.fedorahosted.org/packages/rasdaemon * License : GPL-2 Programming Lang: C Description : utility to receive RAS error messages rasdaemon is a RAS (Reliability, Availability and Serviceability) logging tool. It currently records memory errors, using the EDAC tracing events. EDAC are drivers in the Linux kernel that handle detection of ECC errors from memory controllers for most chipsets on x86 and ARM architectures. This userspace component consists of an init script which makes sure EDAC drivers and DIMM labels are loaded at system startup, as well as a utility for reporting current error counts from the EDAC sysfs files. While the edac-utils package provides similar information, the intent of this project is to add extensive RAS information provided by the ACPI APEI (ACPI Platform Error Interfaces, Section 18 of the specification) over time. Hence, the plan is that this package will grow beyond reporting EDAC information. This package will be maintained by the submitter as part of his daily job responsibilities. And while the submitter is currently a new user of this tool, he will be using it much more frequently and will be providing new and extended functionality over time.
Bug#762838: bug#762838 -- bind9 crash on update
Just upgraded to this version from one about 1 month old from sid and see the same problem; named will run for a few minutes, and then the messages shown appear in syslog. There were no changes to any of the BIND config files. The 9.10.0 version in experimental seems to be more stable. -- Ciao, al -- Al Stone Debian Developer E-mail: a...@debian.org http://www.debian.org -- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#734433: python-jenkinsapi: Invalid field Python-Verions in binary package metadata
On 01/06/2014 11:27 PM, Stuart Prescott wrote: Package: python-jenkinsapi Version: 0.2.16-1 Severity: minor Dear Maintainer, The latest upload of python-jenkinsapi generates the following package metadata: Package: python-jenkinsapi Version: 0.2.16-1 Installed-Size: 207 Maintainer: Al Stone a...@debian.org Architecture: all Provides: python2.7-jenkinsapi Depends: python-lxml, python-bs4, python-pkg-resources, python (= 2.7), python ( 2.8), python-requests, python-tz Description: bindings for Python usage of the Jenkins remote API Homepage: http://pypi.python.org/pypi/jenkinsapi Description-md5: ca8ada3827a339bf9b131dd4732d148b Python-Verions: 2.7 Section: python Priority: optional Filename: pool/main/p/python-jenkinsapi/python-jenkinsapi_0.2.16-1_all.deb Size: 32354 MD5sum: 0d4e5f8b8df5c5dbcb9bc094ebf4a562 SHA1: af07bb23769a248bc0dbe1beeac632f4e960cb02 SHA256: 92998df4314dde8e38fff127c8f274826ac07205d8f3d7c46c218fe187b1d342 The field Python-Verions (if included at all) should be Python-Versions. cheers Stuart Argh. What a stupid typo :(. Thanks. I'll fix and re-upload. -- Ciao, al -- Al Stone Debian Developer E-mail: a...@ahs3.nethttp://www.debian.org a...@debian.org -- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#734414: RM: q-tools -- ROM; q-tools is dead upstream, low popcnt
Package: ftp.debian.org Severity: normal This package has become dead upstream and appears to no longer be actively maintained anywhere. Given also that this package has a very low popcnt, it is time for it to slink off into the sunset. Please remove it from the archives when possible. Thanks. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#731786: q-tools: please migrate to guile-2.0
On 12/09/2013 12:20 PM, Rob Browning wrote: Package: q-tools Version: 0.4-1 I'm trying to have guile-1.6 (and soon guile-1.8) removed from unstable, please migrate to guile-2.0 (or at least guile-1.8) as soon as possible. Thanks I've asked that this package be removed from the archive; it is dead upstream, has really low popcnt, and I no longer use it. As soon as the package is removed, this bug should get handled properly. -- Ciao, al -- Al Stone Debian Developer E-mail: a...@debian.org http://www.debian.org -- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#725704: xserver-xorg-video-radeon: driver overheats laptop, forces constant fan usage
On 10/07/2013 09:22 AM, Michel Dänzer wrote: On Mon, 2013-10-07 at 09:04 -0600, Al Stone wrote: [...] on using the radeon driver, my laptop now stays very warm constantly, and the cooling fan never stops running (over 24 hours now). On checking, it appears to be running 5-10 degrees Centigrade warmer all the time, just over the fan trip point. The radeon device is: 02:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] RV710/M92 [Mobility Radeon HD 4530/4570/545v] [1002:9553] Can you try booting a 3.11 kernel with radeon.dpm=1 on the kernel command line? Sure. What's changed between 3.10 and 3.11 that would have an affect? Just DPM? -- Ciao, al -- Al Stone Debian Developer E-mail: a...@debian.org http://www.debian.org -- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#725704: xserver-xorg-video-radeon: driver overheats laptop, forces constant fan usage
On 10/07/2013 09:22 AM, Michel Dänzer wrote: On Mon, 2013-10-07 at 09:04 -0600, Al Stone wrote: [...] on using the radeon driver, my laptop now stays very warm constantly, and the cooling fan never stops running (over 24 hours now). On checking, it appears to be running 5-10 degrees Centigrade warmer all the time, just over the fan trip point. The radeon device is: 02:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] RV710/M92 [Mobility Radeon HD 4530/4570/545v] [1002:9553] Can you try booting a 3.11 kernel with radeon.dpm=1 on the kernel command line? Aha. That is much, much better. 3.11 without radeon.dpm=1 behaves the same as 3.10; 3.11 _with_ radeon.dpm=1 quiets everything down. I don't know why it had not occurred to me it could be the fan for the radeon, not the CPUs :(. That being said, it seems like radeon.dpm=1 should be the default behavior. -- Ciao, al -- Al Stone Debian Developer E-mail: a...@debian.org http://www.debian.org -- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#714425: acpica-tools: acpidump does not accept old acpidump command-line options
On 07/25/2013 02:50 AM, Paul Wise wrote: On Wed, 2013-07-24 at 17:14 -0600, Al Stone wrote: Do you have a preference? The wrapper sounds like a workaround. My preference would be for you to ask the new upstream to add support for the old acpidump command-line options. Based on the --help output it wouldn't be much work. More concerning is #714426, that should probably be an RC bug? Bug #714426 will be fixed with next upload (most likely today, if build tests pass). I need to apologize, too. I misspoke :(. I had been looking at the wrong version of acpidump because of my PATH setup. The new version has basically the same command line as the old version. There are no --output or --binary parameters, but there are -o and -b, respectively, that do the same thing. Is that sufficient? Or was it the long parameter names that were wanted? -- Ciao, al -- Al Stone Debian Developer E-mail: a...@ahs3.nethttp://www.debian.org a...@debian.org -- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#717332: please create a debian-cross ML
Seconded. I'd appreciate having this available for both of my day jobs. -- Ciao, al -- Al Stone Debian Developer E-mail: a...@debian.org http://www.debian.org -- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#707747: RM: acovea -- ROM; dead upstream, low popcon, and no compatibility with new library versions
Package: ftp.debian.org Severity: normal This package is essentially dead upstream. The developer has decided to forgo any new development on it and in fact has not kept acovea up-to-date with the new versions of the libraries that it uses (even though it is that same person upstream). Further, I have no desire to do the porting work necessary to bring acovea up to date -- it would be extensive but the software does not have the broad appeal I see as needed to justify the work. I should have removed this a long time ago, actually. . -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#704321: O: dmidecode -- SMBIOS/DMI table decoder
I actually need to use this package quite a bit over the next few months and am willling to adopt it. Luk: does take over maintenance imply adopting the package, or just a desire to help? Or do we need to team maintain it? -- Ciao, al -- Al Stone Debian Developer E-mail: a...@debian.org http://www.debian.org -- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#703711: acpidump: please put acpixtract under the alternatives handler so alternate versions can be made available
Package: acpidump Version: 20100513-3.1 Severity: normal Tags: patch In the process of putting together updates for the iasl package elsewhere (see the acpica-unix source package), it was noticed this package also provides an acpixtract command. What the differences are (other than age) are unknown. In order to provide both versions, the acpica-unix package puts acpixtract under the alternatives handler; if this package could also do so, we can avoid package conflicts. Patch is attached. -- System Information: Debian Release: 7.0 APT prefers unstable APT policy: (900, 'unstable'), (500, 'stable-updates'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-4-amd64 (SMP w/8 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages acpidump depends on: ii libc6 2.13-38 ii perl 5.14.2-20 acpidump recommends no packages. acpidump suggests no packages. -- no debconf information diff -urN acpidump-20100513/debian/acpidump.postinst acpidump-20100513-patch/debian/acpidump.postinst --- acpidump-20100513/debian/acpidump.postinst 1969-12-31 17:00:00.0 -0700 +++ acpidump-20100513-patch/debian/acpidump.postinst2013-03-22 09:43:15.0 -0600 @@ -0,0 +1,10 @@ +#!/bin/sh +set -e + +BINDIR=/usr/bin +MANDIR=/usr/share/man/man1 +update-alternatives --install $BINDIR/acpixtract acpixtract \ + $BINDIR/acpixtract-acpidump 90 \ +--slave $MANDIR/man1/acpixtract.1.gz acpixtract.1.gz \ +$MANDIR/man1/acpixtract-acpidump.1 + diff -urN acpidump-20100513/debian/acpidump.prerm acpidump-20100513-patch/debian/acpidump.prerm --- acpidump-20100513/debian/acpidump.prerm 1969-12-31 17:00:00.0 -0700 +++ acpidump-20100513-patch/debian/acpidump.prerm 2013-03-22 09:43:29.0 -0600 @@ -0,0 +1,8 @@ +#!/bin/sh +set -e + +BINDIR=/usr/bin +if [ ! -e $BINDIR/acpixtract-acpidump ] +then +update-alternatives --remove acpixtract $BINDIR/acpixtract-acpidump +fi diff -urN acpidump-20100513/debian/rules acpidump-20100513-patch/debian/rules --- acpidump-20100513/debian/rules 2010-11-12 23:16:01.0 -0700 +++ acpidump-20100513-patch/debian/rules2013-03-22 09:41:32.0 -0600 @@ -63,7 +63,7 @@ # Add here commands to install the package into debian/acpidump. install -d $(CURDIR)/debian/acpidump/usr/bin install -m 755 acpidump/acpidump acpixtract/acpixtract \ - $(CURDIR)/debian/acpidump/usr/bin + $(CURDIR)/debian/acpidump/usr/bin/acpixtract-acpidump [ ! -f turbostat/turbostat ] || \ install -m 755 turbostat/turbostat \ $(CURDIR)/debian/acpidump/usr/bin -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#653227: acpica-unix: New upstream release 20121114 whit full
Just an FYI: did a little re-thinking and made the package closer to pure upstream. New versions are available here: $ dget http://downloads.ahs3.net/packages/acpica-tools/acpica-unix_20130117-2.dsc If there's anything I can do to help get this updated, just let me know. I could NMU into experimental, if that would help. Thanks. -- Ciao, al -- Al Stone Debian Developer E-mail: a...@ahs3.nethttp://www.debian.org a...@debian.org -- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#653227: acpica-unix: New upstream release 20121114 whit full
Howdy. Seeing as how I needed to do this any way, I've gone ahead and put together a .deb of the latest source as of 2013-01-23. I've submitted the same source and patches to Fedora for inclusion there also, and reconciled the patches so the same set is being used in both places (apart from packaging differences). The other thing I needed for my work is to enable the rest of the commands in the ACPICA source. I fully expect to be using all of them a lot over the next couple of years, it turns out. Further, I've enabled some basic testing of the commands, and updated the debian/rules file so it uses the newer, simpler debhelper. I'm sure I could have done more. This is not completely lintian clean (all warnings, but I dislike even those). However, I thought you might find this useful since it would close this bug (#653227) as well as bug #588388. Whether it will solve #407708 or not, I do not know yet. My updated versions of this package can be retrieved with: $ dget http://downloads.ahs3.net/packages/acpica-tools/acpica-unix_20130123-1.dsc Fedora versions are also available, if you need them. Thanks. Hope this helps. -- Ciao, al -- Al Stone Debian Developer E-mail: a...@debian.org http://www.debian.org -- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#653744: libevocosm is fixed, but acovea still ftbfs
On 09/11/2012 02:28 PM, Matthias Klose wrote: unblock 653744 by 658577 thanks libevocosm is fixed, but acovea still ftbfs: Correct; I'm still working through the problems here. It turns out there was a major change in the ABIs being used but acovea was not updated (and I haven't had a lot of time to fix it yet). So, it's in progress still. -- Ciao, al -- Al Stone Debian Developer E-mail: a...@ahs3.nethttp://www.debian.org a...@debian.org -- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#683460: python-jenkinsapi: missing dependencies
On 08/18/2012 01:59 PM, Jakub Wilk wrote: * Jakub Wilk jw...@debian.org, 2012-08-01, 00:41: In a minimal chroot: | $ jenkins_invoke | Traceback (most recent call last): | File /usr/bin/jenkins_invoke, line 5, in module | from pkg_resources import load_entry_point | ImportError: No module named pkg_resources This still happens with python-jenkinsapi 0.1.11-4. My apologies; this has been corrected with 0.1.11-5 which has been uploaded. Thank you for letting me know. -- Ciao, al -- Al Stone Debian Developer E-mail: a...@ahs3.nethttp://www.debian.org a...@debian.org -- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#684304: python-jenkinsapi: uninstallable: depends on 2.6 and 2.7 (sic!)
On 08/08/2012 09:00 AM, Jakub Wilk wrote: Package: python-jenkinsapi Version: 0.1.11-3 Severity: grave Justification: renders package unusable # apt-get install python-jenkinsapi Reading package lists... Done Building dependency tree Reading state information... Done Some packages could not be installed. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming. The following information may help to resolve the situation: The following packages have unmet dependencies: python-jenkinsapi : Depends: 2.6 but it is not installable Depends: 2.7 but it is not installable E: Unable to correct problems, you have held broken packages. Argh. I'm investigating; my apologies for missing this. -- Ciao, al -- Al Stone Debian Developer E-mail: a...@ahs3.nethttp://www.debian.org a...@debian.org -- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#684145: python-jenkinsapi: Missing build-depends on python-setuptools
On 08/07/2012 06:00 AM, Jeremy Bicha wrote: Also, are you sure that python-jenkinsapi shouldn't be Architecture: all ? Jeremy Sigh. Do not work on packages after a 16 hour work day :(. Yup, this has been fixed, as well as the build-dep. Should be uploaded in a hour or two. -- Ciao, al -- Al Stone Debian Developer E-mail: a...@ahs3.nethttp://www.debian.org a...@debian.org -- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#683458: python-jenkinsapi: empty package (after rebuild)
On 07/31/2012 04:08 PM, Jakub Wilk wrote:
Source: python-jenkinsapi
Version: 0.1.11-1
Severity: serious
I rebuilt python-jenkinsapi in a minimal unstable chroot. The resulting
binary package was virtually empty:
$ dpkg -c python-jenkinsapi_0.1.11-1_all.deb | grep -v /$
-rw-r--r-- root/root 156 2012-07-25 01:21
./usr/share/doc/python-jenkinsapi/changelog.Debian.gz
-rw-r--r-- root/root 3027 2012-07-05 00:35
./usr/share/doc/python-jenkinsapi/README.rst
-rw-r--r-- root/root 2679 2012-07-25 01:21
./usr/share/doc/python-jenkinsapi/copyright
The interesting parts of the build log:
|dh_auto_build
| Can't exec pyversions: No such file or directory at
/usr/share/perl5/Debian/Debhelper/Buildsystem/python_distutils.pm line 120.
| Use of uninitialized value $python_default in substitution (s///) at
/usr/share/perl5/Debian/Debhelper/Buildsystem/python_distutils.pm line 121.
| Use of uninitialized value $python_default in substitution (s///) at
/usr/share/perl5/Debian/Debhelper/Buildsystem/python_distutils.pm line 122.
[...]
|dh_auto_install
| Can't exec pyversions: No such file or directory at
/usr/share/perl5/Debian/Debhelper/Buildsystem/python_distutils.pm line 120.
| Use of uninitialized value $python_default in substitution (s///) at
/usr/share/perl5/Debian/Debhelper/Buildsystem/python_distutils.pm line 121.
| Use of uninitialized value $python_default in substitution (s///) at
/usr/share/perl5/Debian/Debhelper/Buildsystem/python_distutils.pm line 122.
[...]
|dh_gencontrol
| dpkg-gencontrol: warning: Depends field of package python-jenkinsapi:
unknown substitution variable ${python:Depends}
| dpkg-gencontrol: warning: Depends field of package python-jenkinsapi:
unknown substitution variable ${shlibs:Depends}
Very interesting; I built this via pbuilder to check for such things
so I'll double check what happened there. Thanks for reporting this.
--
Ciao,
al
--
Al Stone Debian Developer
E-mail: a...@ahs3.nethttp://www.debian.org
a...@debian.org
--
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#682114: ITP: python-jenkinsapi -- bindings for Python usage of the Jenkins remote API
Package: wnpp Severity: wishlist Owner: Al Stone a...@debian.org * Package name: python-jenkinsapi Version : 0.1.11 Upstream Author : Salim Fadhley s...@stodge.org * URL : https://github.com/salimfadhley/jenkinsapi * License : MIT Programming Lang: Python Description : bindings for Python usage of the Jenkins remote API Jenkins is the market leading continuous integration system, originally created by Kohsuke Kawaguchi. This API makes Jenkins even easier to use by providing an easy to use conventional python interface. Jenkins (and its predecessor Hudson) are useful projects for automating common development tasks (e.g., unit-testing, production batches) - but they are somewhat Java-centric. Thankfully the designers have provided an excellent and complete REST interface. This library wraps up that interface as more conventional Python objects in order to make most Jenkins-oriented tasks simpler. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#670680: armhf sigsegv's on task switch
Source: python-greenlet
Severity: important
Tags: upstream patch
The 0.3.1 version of python-greenlet does not seem to behave on
armhf. The following code will show the problem:
from greenlet import greenlet
def test1():
print 12
gr2.switch()
print 34
def test2():
print 56
gr1.switch()
print 78
print 'Correct answer is:'
print '12'
print '56'
print '34'
print 'Actual answer is:'
gr1 = greenlet(test1)
gr2 = greenlet(test2)
gr1.switch()
However, the 0.3.3 version will not compile, either. So, the attached
patch (sorry, not my best work ever ... I'm in a hurry) does two things:
(1) add -fomit-frame-pointer to the compile so that r7 can actually be
saved, and (2) changes platform/switch_arm32_gcc.h to incorporate the
latest upstream changes (which were insufficient) and be more conversative
in what gets saved on task switch. With the changes, 0.3.3 builds on
armhf and passes the test suite with no errors.
Index: python-greenlet-0.3.3/setup.py
===
--- python-greenlet-0.3.3.orig/setup.py 2012-02-08 18:34:38.0 +
+++ python-greenlet-0.3.3/setup.py 2012-04-27 21:34:57.0 +
@@ -7,6 +7,10 @@
if sys.platform == openbsd4 and os.uname()[-1] == i386:
os.environ[CFLAGS] = (%s %s % (os.environ.get(CFLAGS, ), -Os)).lstrip()
+# workaround segfaults on ARMv7
+if sys.platform == linux2 and os.uname()[-1] == armv7l:
+os.environ[CFLAGS] = (%s %s % (os.environ.get(CFLAGS, ), -fomit-frame-pointer)).lstrip()
+
try:
from setuptools import setup, Extension
setuptools_args = dict(test_suite='tests.test_collector', zip_safe=False)
Index: python-greenlet-0.3.3/platform/switch_arm32_gcc.h
===
--- python-greenlet-0.3.3.orig/platform/switch_arm32_gcc.h 2012-02-08 18:34:38.0 +
+++ python-greenlet-0.3.3/platform/switch_arm32_gcc.h 2012-04-27 21:40:55.0 +
@@ -25,7 +25,20 @@
#ifdef SLP_EVAL
#define STACK_MAGIC 0
-#define REGS_TO_SAVE r4, r5, r6, r7, r8, r9, lr
+#define REGS_TO_SAVE_GENERAL r4, r5, r6, r7, r8, r9, \
+ r10, r11, ip, sp, lr, pc
+#if defined(__SOFTFP__)
+#define REGS_TO_SAVE REGS_TO_SAVE_GENERAL
+#elif defined(__VFP_FP__)
+#define REGS_TO_SAVE REGS_TO_SAVE_GENERAL, d8, d9, d10, d11, \
+ d12, d13, d14, d15
+#elif defined(__MAVERICK__)
+#define REGS_TO_SAVE REGS_TO_SAVE_GENERAL, mvf4, mvf5, mvf6, mvf7, \
+ mvf8, mvf9, mvf10, mvf11, \
+ mvf12, mvf13, mvf14, mvf15
+#else
+#define REGS_TO_SAVE REGS_TO_SAVE_GENERAL, f4, f5, f6, f7
+#endif
static int
slp_switch(void)
@@ -33,8 +46,8 @@
void *fp;
register int *stackref, stsizediff;
__asm__ volatile ( : : : REGS_TO_SAVE);
-__asm__ volatile (str fp,%0 : =m (fp));
-__asm__ (mov %0,sp : =g (stackref));
+__asm__ volatile (mov r0, fp\n\tstr r0, %0 : =m (fp) : : r0);
+__asm__ (mov %0,sp : =r (stackref));
{
SLP_SAVE_STATE(stackref, stsizediff);
__asm__ volatile (
@@ -45,9 +58,9 @@
);
SLP_RESTORE_STATE();
}
-__asm__ volatile (ldr fp,%0 : : m (fp));
+__asm__ volatile (ldr r0, %0\n\tmov fp, r0 : : m (fp) : r0);
__asm__ volatile ( : : : REGS_TO_SAVE);
return 0;
}
-#endif
\ No newline at end of file
+#endif
Bug#653744: full log attached
On 01/09/2012 11:19 PM, Aron Xu wrote: I believe here's some useful information in the log: checking libevocosm/evocosm.h usability... no checking libevocosm/evocosm.h presence... yes configure: WARNING: libevocosm/evocosm.h: present but cannot be compiled configure: WARNING: libevocosm/evocosm.h: check for missing prerequisite headers? configure: WARNING: libevocosm/evocosm.h: see the Autoconf documentation configure: WARNING: libevocosm/evocosm.h: section Present But Cannot Be Compiled configure: WARNING: libevocosm/evocosm.h: proceeding with the preprocessor's result configure: WARNING: libevocosm/evocosm.h: in the future, the compiler will take precedence configure: WARNING: ## -- ## configure: WARNING: ## Report this to the AC_PACKAGE_NAME lists. ## configure: WARNING: ## -- ## checking for libevocosm/evocosm.h... yes Thanks. I'm looking into this. Note that it is completely architecture-independent (i.e., that it was discovered with armhf is irrelevant -- it occurs on amd64 the same way. -- Ciao, al -- Al Stone Debian Developer E-mail: a...@ahs3.nethttp://www.debian.org a...@debian.org -- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#620753: RM: qprof -- ROM; dead upstream, low popcon count
Package: ftp.debian.org Severity: normal This package has been static upstream for many years now. Given that, and given there are other similar tools, and given a very low popcon count, there seems to be no need to keep it around. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#615166: glusterfs-server: RPC issues with glusterfs 3.1.2-3
Just an observation: if I purge the sid gluster packages, NFS, and rpcbind, then use the package structure suggested by Louis Zuckerman, and install glusterd and glusterfs-client, then I no longer see this issue. I suspect it has to do with there being a glusterfsd.vol file at all. I would suggest that Louis' packages should also have a Replaces: or Conflicts: with glusterfs-server. -- Ciao, al -- Al Stone Debian Developer E-mail: a...@ahs3.nethttp://www.debian.org a...@debian.org -- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#578323: RM: acovea-results -- ROM; dead upstream, provides little value
Package: ftp.debian.org Severity: normal This package aggregated data showing the results of running the acovea tool with several benchmarks. The results are too dated to be of use, the method used for running benchmarks with acovea has changed dramatically, and hence these provide little or no value to the end user. Since the popcon count is pretty low, there seems to be little harm in removing the package. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#578326: ITP: libbrahe -- A heterogeneous C library of interesting numeric functions
Package: wnpp Severity: wishlist Owner: Al Stone a...@debian.org Owner: Al Stone a...@debian.org Package name: libbrahe Version : 1.2.0 Upstream Author : Scott Robert Ladd scott.l...@coyotegulch.com URL : http://www.coyotegulch.com/products/brahe License : GPLv3 Programming Lang: C Description : A heterogeneous C library of interesting numeric functions This library provides: * a function for rounding floating point values to a specific number of digits * several pseudo-random number generators, including the Mersenne Twister, various algorithms by Marsaglia, and ISAAC * least common multiple and greatest common denominator functions * a few trigonometry functions for finding the inversions of hyperbolic sine, cosine, and tangent This library is also used by libevocosm, which is in turn the foundation for Acovea, used to determine optimal compiler optimizations -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#525737: O: oprofile -- system-wide profiler for Linux systems
Package: wnpp Severity: normal I am orphaning the oprofile package. I no longer use this package much, and it needs a lot more care than I have the time or inclination to provide these days (including an upgrade to the latest upstream version). OProfile is used by quite by quite a few folks so it deserves to have a good home. The package description is: OProfile is a performance profiling tool for Linux systems, capable of profiling all running code at low overhead. It consists of a daemon for collecting sample data, plus several post-profiling tools for turning data into information. Using OProfile also requires a kernel module, either contained in a separate package called 'oprofile-modules' for 2.2 and 2.4 kernels, or for 2.6 kernels, the OProfile kernel module is part of the Linux kernel source and must be built from the 'kernel-source' package. . OProfile leverages the hardware performance counters of the x86 CPU and the PMU (Performance Monitoring Unit) of the ia64 CPU to enable profiling of a wide variety of interesting statistics, which can also be used for basic time-spent profiling. All code is profiled: hardware and software interrupt handlers, kernel modules, the kernel, shared libraries, and applications (the only exception being the OProfile interrupt handler itself). Note that different architectures can use different hardware mechanisms to collect data. . OProfile is currently in alpha status; however it has proven stable over a large number of differing configurations. As always, there is no warranty. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#525744: O: laptop-net -- Automatically adapt laptop Ethernet
Package: wnpp Severity: normal I am orphaning the laptop-net package. I no longer use this package and no longer have the time nor inclination to give it the care it needs. Before adopting the package, be aware that NetworkManager does some but not all of the same things, and it might make sense to subsume laptop-net functionality within NetworkManager. The package description is: The laptop-net package supports the built-in Ethernet of laptops by providing several integrated features that automatically adapt the laptop to the network environment. The package is easily configured to support a wide variety of network environments, and supports manual as well as automatic management of the network interface. . Laptop-net can automatically: start and stop the network interface at appropriate times; disable the network interface when the network cable is removed, and enable it when the cable is inserted; select the network interface's IP address, either by probing the network for known hosts or by use of the DHCP protocol; customize the laptop's software configuration to match the network interface's IP address. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#525745: O: libpfm3-3.2 -- Performance Monitor Unit (PMU) -- run-time libraries
Package: wnpp Severity: normal I am orphaning the libpfm3-3.2 package. I no longer use this package and do not have the time nor the inclination to maintain it. Free to a good home. The package description is: This package contains a shared library for applications using the IA-64 Performance Monitor Unit (PMU). This version supports several modern procesors: both the Itanium and Itanium 2 processors, as well as Pentium M/P6 cores, and AMD x86_64 processors. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#525748: O: pfmon -- Tool for using CPU Performance Monitoring Units (PMUs)
Package: wnpp Severity: normal I am orphaning the pfmon package. I no longer use this package, and no longer have the time nor the inclination to maintain it. The package description is: This package contains pfmon, a tool to monitor performance using CPU Performance Monitoring Units (PMUs). Pfmon can monitor standalone programs or the entire system on both UP and SMP Linux systems. This version supports both the Itanium and Itanium 2 processors, Pentium M/P6 and AMD x86_64. It requires a kernel perfmon-2.x subsystem to function properly, which implies at least a 2.6.12 kernel. . A working perfmon kernel module is also required (provided by default with Debian 2.6.x kernels). -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#512694: pidgin-facebookchat: package should depend on the pidgin package
Jonathan Davies wrote: 2009/1/23 Al Stone a...@ahs3.net: Jonathan Davies wrote: 2009/1/22 Al Stone a...@debian.org: I installed this package but did not have pidgin installed. Hence, I could not use the package until I installed pidgin. This should have been taken care of in the dependencies. This plugin is for both Pidgin and libpurple messengers (such as finch, adium, etc). Ah -- I was not aware of that. Now I understand the lack of dependencies. It does depend on libpurple, so something does get pulled in. Would it make any sense to have a pidgin-facebookchat package that depends on pidgin, a finch-facebookchat package that depends on finch, and so on? Or would that just add mindless clutter? For a simple .so file, I think that that would would add the later. But for the next upload I'll add finch and pidgin to suggests so the user knows what to pull in as well. Jonathan That works for me. Thanks for the quick response. -- Ciao, al -- Al Stone Alter Ego: E-mail: a...@ahs3.net Debian Developer -or- http://www.debian.org E-mail: ahst...@comcast.net a...@debian.org -- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#512694: pidgin-facebookchat: package should depend on the pidgin package
Jonathan Davies wrote: 2009/1/22 Al Stone a...@debian.org: I installed this package but did not have pidgin installed. Hence, I could not use the package until I installed pidgin. This should have been taken care of in the dependencies. This plugin is for both Pidgin and libpurple messengers (such as finch, adium, etc). Ah -- I was not aware of that. Now I understand the lack of dependencies. I could probably add pidgin to Suggests. However there may be people who use finch, who also use this package, who do not want pidgin and bits of GTK and GNOME pulled in. What do you think could be done? Would it make any sense to have a pidgin-facebookchat package that depends on pidgin, a finch-facebookchat package that depends on finch, and so on? Or would that just add mindless clutter? -- Ciao, al -- Al Stone Alter Ego: E-mail: a...@ahs3.net Debian Developer -or- http://www.debian.org E-mail: ahst...@comcast.net a...@debian.org -- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#512694: pidgin-facebookchat: package should depend on the pidgin package
Package: pidgin-facebookchat Version: 1.47-1 Severity: normal I installed this package but did not have pidgin installed. Hence, I could not use the package until I installed pidgin. This should have been taken care of in the dependencies. -- System Information: Debian Release: 5.0 APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.26-1-686 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages pidgin-facebookchat depends on: ii libc6 2.7-18 GNU C Library: Shared libraries ii libpurple02.4.3-4multi-protocol instant messaging l pidgin-facebookchat recommends no packages. pidgin-facebookchat suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#455274: diff for 3.1.0-4.1 NMU
Pierre Habouzit wrote: Hi, Attached is the diff for my libcoyotl 3.1.0-4.1 NMU. It sure would have been nice if someone had at least *attempted* to contact me before this NMU. There is actually a reason for not having uploaded this package with a change similar to the one given. I now have to spend more time than I had planned on to get in a proper fix. A little common courtesy -- something that appears to be sorely lacking in Debian lately -- could have gone a long way. -- Ciao, al -- Al Stone Alter Ego: E-mail: [EMAIL PROTECTED] Debian Developer -or- http://www.debian.org E-mail: [EMAIL PROTECTED] [EMAIL PROTECTED] -- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#455274: diff for 3.1.0-4.1 NMU
Pierre Habouzit wrote: On Sun, Mar 16, 2008 at 09:55:18PM +, Al Stone wrote: Pierre Habouzit wrote: Hi, Attached is the diff for my libcoyotl 3.1.0-4.1 NMU. It sure would have been nice if someone had at least *attempted* to contact me before this NMU. There is actually a reason for not having uploaded this package with a change similar to the one given. I now have to spend more time than I had planned on to get in a proper fix. A little common courtesy -- something that appears to be sorely lacking in Debian lately -- could have gone a long way. The bug is open for almost 100 days, it's a release goal and has been advertised as such for months, and is under the 0day NMU policy, and there is an ongoing BSP against g++-4.3 FTBFS going on. There is a patch available, and you didn't react on the bug. I don't touch bugs where I saw a maintainer activity in the first place. Cheers, QED. There is no need to insult my intelligence, or my efforts on Debian. There is an assumption here that I am completely unaware of what's going on with my bugs, the project, and that I have no desire to fix my bugs. An assumption has also been made that because I did not make some sort of announcement in the bug report, that nothing was going on. None of these assumptions are true. What I was trying to point out was that if one had simply asked, they would have found that out. -- Ciao, al -- Al Stone Alter Ego: E-mail: [EMAIL PROTECTED] Debian Developer -or- http://www.debian.org E-mail: [EMAIL PROTECTED] [EMAIL PROTECTED] -- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#446630: opreport error
Is this bug still repeatable with a 2.6.23 or better kernel? I've tried to repeat this on both an Intel Core2 Duo and an AMD Athlon dual-core, and opreport seems to work just fine. -- Ciao, al -- Al Stone Debian Developer E-mail: [EMAIL PROTECTED] http://www.debian.org [EMAIL PROTECTED] -- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#451384: O: llvm -- Low-Level Virtual Machine (LLVM) compiler for C/C++
Package: wnpp Severity: normal I intend to orphan the llvm package. I just do not have the time this package deserves -- and it definitely needs more than one person to maintain it. Keeping the package well-maintained is about as difficult as maintaining GCC, with the added complication that upstream is improving the code very quickly. The package description is: The Low-Level Virtual Machine (LLVM) is a collection of libraries and tools that make it easy to build compilers, optimizers, Just-In-Time code generators, and many other compiler-related programs. LLVM uses a single, language-independent virtual instruction set both as an offline code representation (to communicate code between compiler phases and to run-time systems) and as the compiler internal representation (to analyze and transform programs). This persistent code representation allows a common set of sophisticated compiler techniques to be applied at compile-time, link-time, install-time, run-time, or idle-time (between program runs). . The strengths of the LLVM infrastructure are its extremely simple design (which makes it easy to understand and use), source-language independence, powerful mid-level optimizer, automated compiler debugging support, extensibility, and its stability and reliability. LLVM is currently being used to host a wide variety of academic research projects and commercial projects. LLVM includes C and C++ front-ends (based on GCC 4.0.1), a front-end for a Forth-like language (Stacker), a young scheme front-end, and Java support is in development. LLVM can generate code for X86, SparcV9, PowerPC, or it can emit C code. . NB: this package needs one or more LLVM front-ends (e.g., the package 'llvm-cfe'). -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable') Architecture: i386 (i686) Kernel: Linux 2.6.22-2-686 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#451106: ITP: llvm2 -- Low-Level Virtual Machine (LLVM) compiler for C/C++
Pierre Habouzit wrote: On Wed, Nov 14, 2007 at 02:56:00PM +, Al Stone wrote: Arthur, It seems sort of overkill to do a whole new ITP for LLVM. If you're interested, you could take over the maintenance of the existing LLVM packages, perhaps even put them into team maintenance. I haven't had the time need to maintain the packages, and haven't put it up for adoption yet, mostly because no one else has come forward as willing to do the work... OTOH llvm 2.x is not backward compatible with the 1.x series, and comes some brand new tools, meaning that such a package will go through NEW and stuff like that anyways. It _is_ a brand new package on many aspects. It's unclear to me if llvm should continue to exist in the archive or not, but I disagree with the fact that an ITP is an overkill. Cheers, So there should be a new package name every time upstream introduces significant new functionality? That makes very little sense to me and seems to introduce an awful lot of extra -- and duplicated -- work. And, given the size of this package, adding multiple tens of megabytes to the archives can't help, either. If LLVM had a huge user base, perhaps that would make sense. In this case, however, I think you're better off just taking over the existing package name. -- Ciao, al -- Al Stone Alter Ego: E-mail: [EMAIL PROTECTED] Debian Developer -or- http://www.debian.org E-mail: [EMAIL PROTECTED] [EMAIL PROTECTED] -- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#451106: ITP: llvm2 -- Low-Level Virtual Machine (LLVM) compiler for C/C++
Arthur Loiret wrote: Package: wnpp Severity: wishlist Owner: Arthur Loiret [EMAIL PROTECTED] * Package name: llvm2 Version : 2.1 Upstream Author : LLVM Team, University of Illinois at Urbana-Champaign * URL : http://llvm.org/ * License : LLVM Release License Programming Lang: C++ Description : Low-Level Virtual Machine (LLVM) compiler for C/C++ The Low-Level Virtual Machine (LLVM) is a collection of libraries and tools that make it easy to build compilers, optimizers, Just-In-Time code generators, and many other compiler-related programs. LLVM uses a single, language-independent virtual instruction set both as an offline code representation (to communicate code between compiler phases and to run-time systems) and as the compiler internal representation (to analyze and transform programs). This persistent code representation allows a common set of sophisticated compiler techniques to be applied at compile-time, link-time, install-time, run-time, or idle-time (between program runs). . The strengths of the LLVM infrastructure are its extremely simple design (which makes it easy to understand and use), source-language independence, powerful mid-level optimizer, automated compiler debugging support, extensibility, and its stability and reliability. LLVM is currently being used to host a wide variety of academic research projects and commercial projects. LLVM includes C and C++ front-ends (based on GCC 4.0.1), a front-end for a Forth-like language (Stacker), a young scheme front-end, and Java support is in development. LLVM can generate code for X86, SparcV9, PowerPC, or it can emit C code. Arthur, It seems sort of overkill to do a whole new ITP for LLVM. If you're interested, you could take over the maintenance of the existing LLVM packages, perhaps even put them into team maintenance. I haven't had the time need to maintain the packages, and haven't put it up for adoption yet, mostly because no one else has come forward as willing to do the work... -- Ciao, al -- Al Stone Alter Ego: E-mail: [EMAIL PROTECTED] Debian Developer -or- http://www.debian.org E-mail: [EMAIL PROTECTED] [EMAIL PROTECTED] -- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#429036: bug still exists in latest icedove
Package: icedove Version: 2.0.0.4.dfsg1-2 Followup-For: Bug #429036 I've run into this bug again. It needs to be re-opened and it needs to be resolved. At this point, icedove is now completely unusable with the latest update. -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable') Architecture: i386 (i686) Kernel: Linux 2.6.22-1-686 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages icedove depends on: ii debianutils 2.23.1 Miscellaneous utilities specific t ii fontconfig 2.4.2-1.2generic font configuration library ii libatk1.0-0 1.18.0-2 The ATK accessibility toolkit ii libc6 2.6.1-2 GNU C Library: Shared libraries ii libcairo2 1.4.10-1 The Cairo 2D vector graphics libra ii libfontconfig1 2.4.2-1.2generic font configuration library ii libfreetype62.3.5-1+b1 FreeType 2 font engine, shared lib ii libgcc1 1:4.2.1-5GCC support library ii libglib2.0-02.14.0-2 The GLib library of C routines ii libgtk2.0-0 2.10.13-1The GTK+ graphical user interface ii libhunspell-1.1-0 1.1.9-1 spell checker and morphological an ii libjpeg62 6b-13The Independent JPEG Group's JPEG ii libnspr4-0d 4.6.7-1 NetScape Portable Runtime Library ii libnss3-0d 3.11.7-1 Network Security Service libraries ii libpango1.0-0 1.18.1-1 Layout and rendering of internatio ii libpng12-0 1.2.15~beta5-2 PNG library - runtime ii libstdc++6 4.2.1-5 The GNU Standard C++ Library v3 ii libx11-62:1.0.3-7X11 client-side library ii libxcursor1 1:1.1.9-1X cursor management library ii libxext61:1.0.3-2X11 miscellaneous extension librar ii libxfixes3 1:4.0.3-2X11 miscellaneous 'fixes' extensio ii libxft2 2.1.12-2 FreeType-based font drawing librar ii libxi6 2:1.1.2-1X11 Input extension library ii libxinerama11:1.0.2-1X11 Xinerama extension library ii libxrandr2 2:1.2.1-1X11 RandR extension library ii libxrender1 1:0.9.3-1X Rendering Extension client libra ii libxt6 1:1.0.5-3X11 toolkit intrinsics library ii psmisc 22.5-1 Utilities that use the proc filesy ii zlib1g 1:1.2.3.3.dfsg-5 compression library - runtime icedove recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#407244: llvm: New upstream release (1.9)
Mike Hommey wrote: On Tue, Jan 16, 2007 at 11:00:27PM -0700, Wesley J. Landaker [EMAIL PROTECTED] wrote: Package: llvm Version: 1.8b-1 Severity: normal The new 1.9 upstream release is really great, fixes a lot of bugs, and adds a lot of features. Among them is x86_64 support, much better ARM support, better optimiziers, and improved test framework, a new GCC4-based C and C++ front-end, and a bunch of other nice things. Basically, if you're any kind of serious user of llvm you're really going to want this new upstream release. It would be create to have it packaged. It's so sad to compile/install it by hand when an old version is in Debian! This bug is 226 days old, and no new upload occurred in the last 10 months. Now, the newest release is 2.0, and 2.1 is scheduled for September 27th! Al, do you need help with llvm packaging ? Mike Sigh. Yes, all the help I can get. This package is far larger than I have time to adequately address; a team or even someone willing to adopt would be wonderful. At this point, I'm just slowing things down and this is technology that really needs to get out into the world. Any volunteers? If not, I'll send out an RFA or RFH. -- Ciao, al -- Al Stone Alter Ego: E-mail: [EMAIL PROTECTED] Debian Developer -or- http://www.debian.org E-mail: [EMAIL PROTECTED] [EMAIL PROTECTED] -- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#432467: subversion: svn co on ia64 fails with PROPFIND errors but works just fine on i686
Peter Samuelson wrote: [Al Stone] I then removed /etc/subversion, and now it works. Unfortunately, I did not save a copy of the files that were in that directory. And, I did not check my backup _before_hand -- it turns out that the files weren't in the backup, either. But, that's a different problem. Hrrm. The default /etc/subversion/config and /etc/subversion/servers are entirely empty except for comments and section headers. If you purge then reinstall subversion, it will restore the default files in /etc/subversion. Can you confirm that this does not break your system again? Confirmed. Purge followed by install and svn still works properly. I had tried apt-get install --reinstall previously, too, and it seemed to think there was no need to change the config files. Re-adding the other packages I had installed that depended on subversion (svk, trac) did not cause the problem to recur. My apologies for losing the config files I had -- those appear to be the root of whatever the problem was. If I can find them and reproduce the problem, I'll pass that on. In the meantime, I see no further reason to keep this bug open. I appreciate your patience and efforts in trying to hunt this down. -- Ciao, al -- Al Stone Alter Ego: E-mail: [EMAIL PROTECTED] Debian Developer -or- http://www.debian.org E-mail: [EMAIL PROTECTED] [EMAIL PROTECTED] -- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#432467: subversion: svn co on ia64 fails with PROPFIND errors but works just fine on i686
Peter Samuelson wrote: [Al Stone] tomorrow I'll try bringing all of the installed packages up-to-date. just in case. It's only been since Saturday, but there's 76 updated packages in the queue already. The immediate suspect would be libneon26, but there is only one version of that, 0.26.3-1, which satisfies the dependency in libsvn1. So you and Troy surely have the same version of libneon26. In the Stupid Human Tricks category The upgrades were irrelevant. Same behavior. I tried removing ~/.subversion, but that did not change anything. I then removed /etc/subversion, and now it works. Unfortunately, I did not save a copy of the files that were in that directory. And, I did not check my backup _before_hand -- it turns out that the files weren't in the backup, either. But, that's a different problem. So, I can tell you the workaround -- rm -rf /etc/subversion. But, I can't tell you _what_ about that directory being empty that makes it work; I hadn't changed any of the config files from what they were in the package itself (at least, afaict...). -- Ciao, al -- Al Stone Alter Ego: E-mail: [EMAIL PROTECTED] Debian Developer -or- http://www.debian.org E-mail: [EMAIL PROTECTED] [EMAIL PROTECTED] -- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#432467: subversion: svn co on ia64 fails with PROPFIND errors but works just fine on i686
Peter Samuelson wrote: [Al Stone] The following command to get a copy of an SVN repository fails on an ia64 system: $ svn co http://llvm.org/svn/llvm-project/llvm/trunk anywhere svn: PROPFIND request failed on '/svn/llvm-project/llvm/trunk' svn: PROPFIND of '/svn/llvm-project/llvm/trunk': could not connect to server (http://llvm.org) I don't have an ia64 system so I can't try to reproduce this. Can you try with another http server? For example: There are some available in the Debian Developer's pool of machines; if I can try something out for you, just let me know. $ svn co http://svn.collab.net/repos/svn/trunk/subversion/libsvn_subr subr $ svn co http://svn.collab.net/repos/svn/trunk/subversion/libsvn_subr subr svn: PROPFIND request failed on '/repos/svn/trunk/subversion/libsvn_subr' svn: PROPFIND of '/repos/svn/trunk/subversion/libsvn_subr': could not connect to server (http://svn.collab.net) Also, does non-http repository access work? $ svn co svn://svn.debian.org/pkg-subversion/trunk/debian debian-svn Interesting. Non-http works just fine. Is this starting to look like something on the server side? (If so, by the way, the bug is not grave as it does not render package unusable.) The 'grave' part I debated; this may be an ia64 thing only, which only makes it unusable there. And there's no real way to categorize a bug as deadly but only on a single arch but yes, since the non-http does work, this does not need to be 'grave' any more. ___ pkg-subversion-maintainers mailing list [EMAIL PROTECTED] http://lists.alioth.debian.org/mailman/listinfo/pkg-subversion-maintainers -- Ciao, al -- Al Stone Alter Ego: E-mail: [EMAIL PROTECTED] Debian Developer -or- http://www.debian.org E-mail: [EMAIL PROTECTED] [EMAIL PROTECTED] -- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#432467: subversion: svn co on ia64 fails with PROPFIND errors but works just fine on i686
Hey, Troy! I'd sorta forgotten you were on this team :). Peter: sorry about the address mess; '[EMAIL PROTECTED]' was what should have been in my ~/.reportbugrc :(. Peter Samuelson wrote: [Troy Heber] This is the error you will get if you are behind a proxy and can not access the machine directly. From your ia64 box can you telnet to port 80 of llvm.org? Yes. Works fine -- I've no proxies configured on the subnet, so I expected that to be the case. Everything is NAT'd, but if that was the problem, I'd expect to see that on all the boxes on the same subnet -- but I don't. Or, if it's a transparent proxy, telnet won't necessarily reveal the problem. What will show the problem is to try https, which transparent proxies have to leave alone (or server certs wouldn't be valid): $ svn ls http://svn.collab.net/repos/svn $ svn ls https://svn.collab.net/repos/svn If the second one works and the first does not, you've found your problem. Neither works: ([EMAIL PROTECTED]) svn ls http://svn.collab.net/repos/svn svn: PROPFIND request failed on '/repos/svn' svn: PROPFIND of '/repos/svn': could not connect to server (http://svn.collab.net) ([EMAIL PROTECTED]) svn ls https://svn.collab.net/repos/svn svn: PROPFIND request failed on '/repos/svn' svn: PROPFIND of '/repos/svn': could not connect to server (https://svn.collab.net) Very strange indeedtomorrow I'll try bringing all of the installed packages up-to-date. just in case. It's only been since Saturday, but there's 76 updated packages in the queue already. -- Ciao, al -- Al Stone Alter Ego: E-mail: [EMAIL PROTECTED] Debian Developer -or- http://www.debian.org E-mail: [EMAIL PROTECTED] [EMAIL PROTECTED] -- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#432467: subversion: svn co on ia64 fails with PROPFIND errors but works just fine on i686
Package: subversion Version: 1.4.4dfsg1-1 Severity: grave Justification: renders package unusable The following command to get a copy of an SVN repository fails on an ia64 system: $ svn co http://llvm.org/svn/llvm-project/llvm/trunk anywhere svn: PROPFIND request failed on '/svn/llvm-project/llvm/trunk' svn: PROPFIND of '/svn/llvm-project/llvm/trunk': could not connect to server (http://llvm.org) On multiple i686 systems, also running sid, also running this version of subversion, the exact same checkout works just fine. I've compared all of the config files, and they are the same. Network access to the host works on both ia64 _and_ i686 systems. -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable') Architecture: ia64 Kernel: Linux 2.6.21-2-mckinley (SMP w/2 CPU cores) Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/bash Versions of packages subversion depends on: ii libapr1 1.2.7-8.2The Apache Portable Runtime Librar ii libc6.1 2.5-11 GNU C Library: Shared libraries ii libsvn1 1.4.4dfsg1-1 Shared libraries used by Subversio subversion recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#415095: linux-kernel-headers: please revert addition of typedef for __kernel_dev_t in linux/types.h
Package: linux-kernel-headers Version: 2.6.18-7 Severity: normal Tags: patch Way back in the days of bug#220991, the following two lines of code were added to /usr/include/linux/types.h: /* For util-linux / cryptoloop. How lame. */ typedef __u32 __kernel_dev_t; These are no longer needed -- both util-linux and cryptsetup build from source just fine if I remove them. What's more, having this typedef in types.h causes an FTBS of uclibc for almost all architectures (arm has been hacked to make it work) -- see bug#269721, which could be closed if this code was removed. In fact, it was in trying to build uclibc for ia64 and i386 that I stumbled across this problem. Here's the patch: --- types.h.orig2007-03-15 18:46:00.0 -0600 +++ types.h 2007-03-15 18:46:22.0 -0600 @@ -7,8 +7,6 @@ /* For other kernel headers. */ # include linux/posix_types.h # include asm/types.h -/* For util-linux / cryptoloop. How lame. */ -typedef __u32 __kernel_dev_t; #else #ifdef __KERNEL__ -- System Information: Debian Release: 4.0 APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-4-686 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#360560: adding tags to #360560
tags 360560 + wontfix thanks Tagging this bug as wontfix for now; the chances of it occurring are exceedingly small. A fix would also require rethinking some of the use model as it currently exists and hence upstream changes that are unlikely to occur. Will investigate alternative solutions as time allows... -- Ciao, al -- Al Stone Debian Developer E-mail: [EMAIL PROTECTED] http://www.debian.org [EMAIL PROTECTED] -- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#401810: duplicate package
On Wed, 2006-12-06 at 03:26 +0100, Andreas Barth wrote: Package: libpfm3 Severity: serious Version: 3.2.060926-1 Hi, this package is unnecessary, as libpfm3-3.2 has entered the archive, and there are no reverse dependencies anymore. Cheers, Andi Thanks for the bug report. According to the ftp-masters, this package should be removed automatically once it is noticed that there is no longer a source package that generates it and it has been removed from testing. Both conditions are now true, hence the package should go away automatically. I will double check, though, and make sure this happens. -- Ciao, al -- Al Stone Alter Ego: Open Source and Linux RD Debian Developer Hewlett-Packard Company http://www.debian.org E-mail: [EMAIL PROTECTED][EMAIL PROTECTED] -- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#392955: fixed, waiting NEW queue processing
A fix for this problem has been completed and uploaded. Due to repairs to remove GFDL documentation, the fix is now waiting for processing in the NEW queue. -- Ciao, al -- Al Stone Alter Ego: Open Source and Linux RD Debian Developer Hewlett-Packard Company http://www.debian.org E-mail: [EMAIL PROTECTED][EMAIL PROTECTED] -- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#399261: fixed, waiting in NEW queue
A fix for this problem has been completed and uploaded. Due to repairs to remove GFDL documentation, the fix is now waiting for processing in the NEW queue. -- Ciao, al -- Al Stone Alter Ego: Open Source and Linux RD Debian Developer Hewlett-Packard Company http://www.debian.org E-mail: [EMAIL PROTECTED][EMAIL PROTECTED] -- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#373655: fixed, waiting in NEW queue
A fix for this problem has been completed and uploaded. Due to repairs to remove GFDL documentation, the fix is now waiting for processing in the NEW queue. -- Ciao, al -- Al Stone Alter Ego: Open Source and Linux RD Debian Developer Hewlett-Packard Company http://www.debian.org E-mail: [EMAIL PROTECTED][EMAIL PROTECTED] -- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#395850: fixed, waiting in NEW queue
A fix for this problem has been completed and uploaded. Due to repairs to remove GFDL documentation, the fix is now waiting for processing in the NEW queue. -- Ciao, al -- Al Stone Alter Ego: Open Source and Linux RD Debian Developer Hewlett-Packard Company http://www.debian.org E-mail: [EMAIL PROTECTED][EMAIL PROTECTED] -- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#396236: qprof: FTBFS: missing build-dep libpfm3-3.2-dev
On Mon, 2006-10-30 at 19:01 +0100, Julien Danjou wrote: Package: qprof Version: 0.5.2-4 Severity: serious Hello, There was a problem while autobuilding your package: Automatic build of qprof_0.5.2-4 on avidan by sbuild/i386 98 Build started at 20061030-1857 ** Checking available source versions... Fetching source files... Reading package lists... Building dependency tree... Need to get 439kB of source archives. Get:1 http://ftp.fr.debian.org sid/main qprof 0.5.2-4 (dsc) [606B] Get:2 http://ftp.fr.debian.org sid/main qprof 0.5.2-4 (tar) [366kB] Get:3 http://ftp.fr.debian.org sid/main qprof 0.5.2-4 (diff) [72.0kB] Fetched 439kB in 2s (206kB/s) Download complete and in download only mode ** Using build dependencies supplied by package: Build-Depends: debhelper (= 4.0.0), libatomic-ops-dev, libunwind7-dev [ia64], libpfm3-3.2-dev Checking for already installed source dependencies... debhelper: missing libatomic-ops-dev: missing libpfm3-3.2-dev: missing Checking for source dependency conflicts... /usr/bin/sudo /usr/bin/apt-get --purge $CHROOT_OPTIONS -q -y install debhelper libatomic-ops-dev libpfm3-3.2-dev Reading package lists... Building dependency tree... E: Couldn't find package libpfm3-3.2-dev apt-get failed. Package installation failed Trying to reinstall removed packages: Trying to uninstall newly installed packages: Source-dependencies not satisfied; skipping qprof ** Finished at 20061030-1857 Build needed 00:04:36, 0k disk space This can be closed as soon as libpfm3-3.2 is released from the NEW queue. -- Ciao, al -- Al Stone Alter Ego: Open Source and Linux RD Debian Developer Hewlett-Packard Company http://www.debian.org E-mail: [EMAIL PROTECTED][EMAIL PROTECTED] -- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#395922: RM: oprofile-source -- please remove obsolete package
Package: ftp.debian.org Severity: normal Starting with etch, the Linux kernel will default to 2.6 versions. This package only has use with 2.4 kernels, and little or no time is spent upstream on maintaining it since this functionality has moved into the 2.6 kernel source upstream. This package derives from the oprofile source package; do NOT remove oprofile -- it is still highly useful. Only this part of the results of building oprofile need to be removed. I will be uploading a new version of oprofile soon that reflects this change in the source package. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-1-686 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#393485: FTBFS: error: perfmon2/perfmon.h: No such file or directory
On Mon, 2006-10-16 at 15:56 +0100, Martin Michlmayr wrote: Package: libpfm2 Version: 2.0-6 Severity: serious Automatic build of libpfm2_2.0-6 on coconut0 by sbuild/ia64 0.49 ... gcc -Wall -I/build/tbm/libpfm2-2.0/libpfm/../include -I. -O2 -g -DCONFIG_PFMLIB_GENERIC -DCONFIG_PFMLIB_ITANIUM -DCONFIG_PFMLIB_ITANIUM2 -c pfmlib_common.c In file included from pfmlib_common.c:38: /build/tbm/libpfm2-2.0/libpfm/../include/perfmon/pfmlib.h:28:30: error: perfmon2/perfmon.h: No such file or directory /build/tbm/libpfm2-2.0/libpfm/../include/perfmon/pfmlib.h:29:38: error: perfmon2/pfmlib_compiler.h: No such file or directory In file included from pfmlib_common.c:38: /build/tbm/libpfm2-2.0/libpfm/../include/perfmon/pfmlib.h:72: error: expected specifier-qualifier-list before 'pfarg_reg_t' make[2]: *** [pfmlib_common.o] Error 1 make[2]: Leaving directory `/build/tbm/libpfm2-2.0/libpfm' Please see bug#394564 that asks for the removal of the libpfm2 package. Unless there are objections, I will close this bug as soon as the RM for the package gets closed. -- Ciao, al -- Al Stone Alter Ego: Open Source and Linux RD Debian Developer Hewlett-Packard Company http://www.debian.org E-mail: [EMAIL PROTECTED][EMAIL PROTECTED] -- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#393485: FTBFS: error: perfmon2/perfmon.h: No such file or directory
On Sat, 2006-10-28 at 13:04 -0700, Steve Langasek wrote: On Sat, Oct 28, 2006 at 04:51:59PM +, Al Stone wrote: Automatic build of libpfm2_2.0-6 on coconut0 by sbuild/ia64 0.49 gcc -Wall -I/build/tbm/libpfm2-2.0/libpfm/../include -I. -O2 -g -DCONFIG_PFMLIB_GENERIC -DCONFIG_PFMLIB_ITANIUM -DCONFIG_PFMLIB_ITANIUM2 -c pfmlib_common.c In file included from pfmlib_common.c:38: /build/tbm/libpfm2-2.0/libpfm/../include/perfmon/pfmlib.h:28:30: error: perfmon2/perfmon.h: No such file or directory /build/tbm/libpfm2-2.0/libpfm/../include/perfmon/pfmlib.h:29:38: error: perfmon2/pfmlib_compiler.h: No such file or directory In file included from pfmlib_common.c:38: /build/tbm/libpfm2-2.0/libpfm/../include/perfmon/pfmlib.h:72: error: expected specifier-qualifier-list before 'pfarg_reg_t' make[2]: *** [pfmlib_common.o] Error 1 make[2]: Leaving directory `/build/tbm/libpfm2-2.0/libpfm' Please see bug#394564 that asks for the removal of the libpfm2 package. Unless there are objections, I will close this bug as soon as the RM for the package gets closed. libpfm2 still has multiple reverse-dependencies in testing: qprof, oprofile-source, and pfmon. What is being done about these? oprofile-source is to be removed (see #395922). qprof and pfmon are being repaired (uploading later today with other fixes). -- Ciao, al -- Al Stone Alter Ego: Open Source and Linux RD Debian Developer Hewlett-Packard Company http://www.debian.org E-mail: [EMAIL PROTECTED][EMAIL PROTECTED] -- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#395922: RM: oprofile-source -- please remove obsolete package
On Sat, 2006-10-28 at 21:26 +0100, Adam D. Barratt wrote: retitle 395922 RM: oprofile:oprofile-source -- RoM; obsolete, 2.4 kernels only thanks On Sat, 2006-10-28 at 11:13 -0600, Al Stone wrote: [...] This package derives from the oprofile source package; do NOT remove oprofile -- it is still highly useful. Only this part of the results of building oprofile need to be removed. I will be uploading a new version of oprofile soon that reflects this change in the source package. Once the new source package has been uploaded, the obsolete binary package will be removed semi-automagically. Since the current source package in unstable still builds the package, it won't get removed until the new source is in the archive. For future reference, if a binary package is not built by any source package it will be removed during semi-automagic archive maintenance within a few days of it stopping being built and you don't need to request removal (likewise source packages that have had all their binary packages taken over by another source package). Regards, Adam Thanks for the clarification. The developer's reference was not explicit in this regard; it was inferred, but not explicit. Should I just close/retract this bug then? -- Ciao, al -- Al Stone Alter Ego: Open Source and Linux RD Debian Developer Hewlett-Packard Company http://www.debian.org E-mail: [EMAIL PROTECTED][EMAIL PROTECTED] -- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#365993: developers-reference: [PATCH] further documentation of automative removal of obsolete packages
Package: developers-reference Version: 3.3.7 Followup-For: Bug #365993 Please apply this patch, too, where the automatic removal of packages also needs further explanation. --- developers-reference-3.3.7/developers-reference.sgml2006-04-04 15:41:26.0 -0600 +++ developers-reference-3.3.7.patched/developers-reference.sgml 2006-10-28 15:03:36.0 -0600 @@ -2505,6 +2505,12 @@ removed automatically after the package has been removed from emunstable/em and no package in emtesting/em depends on it. p +If you are simply restructuring a source package so that it no longer +produces one or more binary packages, there is no need to explicitly ask +for the packages that are no longer created to be removed. Such packages +will be removed when the new package structure has been uploaded into +emunstable/em and when no package in emtesting/em depends on it. + p You also have to detail the reasons justifying that request. This is to avoid unwanted removals and to keep a trace of why a package has been removed. For example, you can provide the name of the package that -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-1-686 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) developers-reference depends on no packages. Versions of packages developers-reference recommends: ii debian-policy 3.7.2.2Debian Policy Manual and related d -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#394564: RM: libpfm2 -- deprecated, only usable for Linux 2.4 kernels
Package: ftp.debian.org Severity: normal libpfm2 is used by a very small number of people (5, according to popcon), and is only usable with 2.4 Linux kernels. Since etch will default to 2.6 kernels, this package no longer serves any useful purpose and should be removed from unstable. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-1-686 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#392836: oprofile-source: fails to build
On Fri, 2006-10-13 at 21:46 +0200, Mario 'BitKoenig' Holbe wrote: Package: oprofile-source Version: 0.9.2-1 Hello, oprofile-source fails to build on i686 and for kernel 2.4.27 due to failing arch detection: Is it still necessary to support 2.4 kernels? With etch, the defaults will be 2.6, and oprofile-source is no longer needed. My preference would be to remove oprofile-source completely; would that create a hardship if I did? -- Ciao, al -- Al Stone Alter Ego: Open Source and Linux RD Debian Developer Hewlett-Packard Company http://www.debian.org E-mail: [EMAIL PROTECTED][EMAIL PROTECTED] -- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#393489: ITP: acovea-gtk -- GTK interface for the acovea package
Package: wnpp Severity: wishlist Owner: Al Stone [EMAIL PROTECTED] Package name: acovea-gtk Version : 1.0.1 Upstream Author : Name [EMAIL PROTECTED] URL : http://www.coyotegulch.com/products/acovea/acovea-gtk.html License : GPL Programming Lang: C++, Glade Description : GTK interface for the acovea package ACOVEA (Analysis of Compiler Options via Evolutionary Algorithm) implements a genetic algorithm to find the best options for compiling programs with the GNU Compiler Collection (GCC) C and C++ compilers. Best, in this context, is defined as those options that produce the fastest executable program from a given source code. Acovea is a C++ framework that can be extended to test other programming languages and non-GCC compilers. The Acovea engine ships with a command-line driver called runacovea. This package provides an easier-to-use graphical interface for the engine for those that prefer a GUI to the command-line. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.17-2-686 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#393489: correct upstream author in ITP
Oops. Forgot the important part: Upstream Author: Scott Robert Ladd [EMAIL PROTECTED] -- Ciao, al -- Al Stone Alter Ego: Open Source and Linux RD Debian Developer Hewlett-Packard Company http://www.debian.org E-mail: [EMAIL PROTECTED][EMAIL PROTECTED] -- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#318795: libaio: ran into this bug too
Package: libaio Version: 0.3.104-1 Followup-For: Bug #318795 Just wondering what the status of this bug is; I ran into it today. The workaround is straightforward (adding the symlink) but a -dev package would be much better. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.17-2-686 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#373655: llvm: FTBFS: Unsuported LLVM Target x86_64-unknown-linux-gnu
On Tue, 2006-06-27 at 20:22 +0200, Kurt Roeckx wrote: It's still failing to build in the same way, so I have no idea what changed, and think this bug still affects 1.7-2. The build script should now fail almost immediately on amd64; the prior method made it look as if things were working when in fact they were not. Anyway, the previous version (1.6-1.1) was build succesfully, but now it's not supported anymore? Yes and no. There is no native code generator for amd64 -- at least, not one that anyone has been willing to work on so far. With all of the other changes for 1.7, the code that did work for 1.6 (a C-generating backend) no longer does, and no one had time to work on it. Correcting the build system is possible, but then you end up with .s files containing C source (which of course the assembler does not like). This could be fixed by having amd64 use an older gcc3 front-end, but that's a level of complexity in the packaging that I think is unwarranted for now. I'm going to try to spend some time looking at the x86_64 code generator in the coming months, so perhaps it will be fixed by 1.8 (or 1.9), but clearly the more help available upstream, the more likely it will get done. -- Ciao, al -- Al Stone Alter Ego: Open Source and Linux RD Debian Developer Hewlett-Packard Company http://www.debian.org E-mail: [EMAIL PROTECTED][EMAIL PROTECTED] -- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#377552: RM: prospect -- upstream dead, only works with 2.4 kernels
Package: ftp.debian.org Severity: normal Please remove prospect from sid. Upstream appears to be dead. Without significant effort from upstream, prospect will not be usable with 2.6 kernels (note that #228669 requesting support for 2.6 has now been open for ~2.5 years). Since 2.6 will soon become the default kernel, the package will then become unusable. Further, most if not all of the functionality in prospect is available in other performance analysis tools (e.g., oprofile). Hence, removing the package will not degrade Debian usability. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.17-1-686 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#377081: Recommends unavailable oprofile-modules0.7
On Thu, 2006-07-06 at 17:36 +0200, Luk Claes wrote: Package: prospect Severity: important Version: 5:0.9.8b-8 Your package recommends oprofile-modules0.7 which is not available in unstable (anymore). I have been considering removing this package from unstable completely. This tool still does not work on 2.6 kernels, most of the functionality exists in oprofile, and upstream appears to be dead. Even though I'm part of upstream, too, it does not seem to make sense to continue work on this tool. Would you have any objections to that? I can fix this fairly quickly in the meantime; but, I am curious as to how many folks would object if the package went away completely (popcon shows pretty low usage...). -- Ciao, al -- Al Stone Alter Ego: Open Source and Linux RD Debian Developer Hewlett-Packard Company http://www.debian.org E-mail: [EMAIL PROTECTED][EMAIL PROTECTED] -- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#374917: q-tools doesn't include q-syscollect
On Thu, 2006-06-22 at 12:00 +1000, Ian Wienand wrote: Package: q-tools Version: 0.3-1 Severity: grave Tags: patch Justification: renders package unusable As you can see from http://buildd.debian.org/fetch.php?pkg=q-tools%26ver=0.3-1%26arch=ia64%26stamp=1146456408%26file=log q-syscollect fails to build, but the package still builds. Thus q-tools is shipped without it The attached patch fixes the build. Sort of; there are some problems in the upstream source for x86, too. I'm testing some patches from upstream to get it to build properly. Something we could discuss in another forum is simplifying by removing the libpfm2 package all together and just using libpfm3; does anything require libpfm2? Agreed, it would be much simpler and easier. Older ia64 machines running 2.4 kernels still require libpfm2, though. Granted, that may be a small set; it's my plan to remove libpfm2 as soon as 2.6 kernels are used by default -- perhaps after etch is released. Thanks, -i -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: ia64 Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.15.4 Locale: LANG=en_AU, LC_CTYPE=en_AU (charmap=ISO-8859-1) Versions of packages q-tools depends on: ii guile-1.6 [guile] 1.6.8-3The GNU extension language and Sch ii guile-1.6-slib1.6.8-3Guile SLIB support ii libc6.1 2.3.6-1GNU C Library: Shared libraries an Versions of packages q-tools recommends: pn graphviz none (no description available) ii gs-gpl8.50-1.1 The GPL Ghostscript PostScript int -- no debconf information -- Ciao, al -- Al Stone Alter Ego: Open Source and Linux RD Debian Developer Hewlett-Packard Company http://www.debian.org E-mail: [EMAIL PROTECTED][EMAIL PROTECTED] -- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#195752: laptop-net: this is *nasty*
On Thu, 2006-06-29 at 11:21 -0700, Tyler MacDonald wrote: Package: laptop-net Followup-For: Bug #195752 An upgrade should never, *NEVER* touch the network connection. This could cause all sorts of things to break if other packages are being upgraded at the same time and dpkg is left in a hung state with no terminal. Hell, turning off internet access at all sounds like a critical bug to me. Tyler, I've put together an attempt to fix this, but I haven't uploaded it yet. Could you please test the packages at: http://free.linux.hp.com/~ahs3/laptop-net and see if that works as you expect? I'm pretty sure it will, but I'd sure appreciate a little broader testing before I do an upload. This version should not affect the interface in any way during the upgrade. I've tested this new version on my personal laptop and it appears to have corrected the problem. -- Ciao, al -- Al Stone Alter Ego: Open Source and Linux RD Debian Developer Hewlett-Packard Company http://www.debian.org E-mail: [EMAIL PROTECTED][EMAIL PROTECTED] -- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#195752: #195752: Can somebody mark this bug as grave or critical?
On Thu, 2006-06-29 at 20:43 +0200, martin f krafft wrote: severity 195752 critical thanks also sprach Tyler MacDonald [EMAIL PROTECTED] [2006.06.29.2029 +0200]: But yeah, I'm not in an official position to say, but if this isn't considered a critical or at least grave bug, then I don't know what is. Agreed. I tried to ping the release team on IRC before, but they were all busy it seemed. So since changing severity isn't a final, irreversible action, I am just doing it. I've only recently picked up this package as maintainer. Nonetheless, I agree it's a very nasty bug. As a long-time user, doing updates via the network all the time, I'm surprised I haven't run into it myself My apologies that the bug has stayed open for so long; I'm still sorting through all the bug reports to understand and prioritize them. This one definitely goes to the top of the list of Things To Do and I'll repair it as quickly as I can. -- Ciao, al -- Al Stone Alter Ego: Open Source and Linux RD Debian Developer Hewlett-Packard Company http://www.debian.org E-mail: [EMAIL PROTECTED][EMAIL PROTECTED] -- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#374917: q-tools doesn't include q-syscollect
On Thu, 2006-06-22 at 12:00 +1000, Ian Wienand wrote: As you can see from http://buildd.debian.org/fetch.php?pkg=q-tools%26ver=0.3-1%26arch=ia64%26stamp=1146456408%26file=log q-syscollect fails to build, but the package still builds. Thus q-tools is shipped without it The attached patch fixes the build. Yes and no. q-syscollect does now attempt to build, but it also needs to come up-to-date with respect to the most recent perfmon interface. I have a partial fix for this available but am waiting on the remainder of the fix from upstream. -- Ciao, al -- Al Stone Alter Ego: Open Source and Linux RD Debian Developer Hewlett-Packard Company http://www.debian.org E-mail: [EMAIL PROTECTED][EMAIL PROTECTED] -- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#366446: spew: minor typo in the output (transfer is not spelled properly)
Package: spew Version: 1.0.5-1 Severity: minor In the output from spew, the word transfer is not spelled correctly; e.g., in: RTR:35518.08 KiB/s Tranfser time: 00:00:29IOPS: 554.97 -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.16-1-686 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
