Re: 0.01-6 > 0.1-3 ?????
> What exactly do you mean by numerically? Is 0.1 == 0.01 == 0.1 == > 1.0 == 10 == 10? What should be watched out for? >From the debian policy manual (section 4): "The strings are compared from left to right. First the initial part of each string consisting entirely of non-digit characters is determined. These two parts (one of which may be empty) are compared lexically. If a difference is found it is returned. The lexical comparison is a comparison of ASCII values modified so that all the letters sort earlier than all the non-letters. Then the initial part of the remainder of each string which consists entirely of digit characters is determined. The numerical values of these two parts are compared, and any difference found is returned as the result of the comparison. For these purposes an empty string (which can only occur at the end of one or both version strings being compared) counts as zero. These two steps (comparing and removing initial non-digit strings and initial digit strings) are repeated until a difference is found or both strings are exhausted." randolph -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [REQ] rebuild gmetadom, gtkmathview and lablgtkmathview on HPPA
In reference to a message from Stefano Zacchiroli, dated Apr 10: > I and the upstream author have fixed the C++ problem that inhibit > gmetadom to build on HPPA with g++ 3.0. > > Could someone then rebuilt gmetadom and two of the packages that depend > on it on HPPA? if you upload new sources/versions they will automatically be retried, please check the buildd logs at http://buildd.debian.org/ to see the status. > The three packages are the ones of the subject given in the order in > which they have to be rebuilt. (They depends on each other in this order > so the need is to: build one, install it and the proceed with the > following one). assuming your packages declare proper build-dependencies they will be automatically rebuilt in the right order. thanks randolph pgp82gnrjZKqA.pgp Description: PGP signature
Re: gmetadom failure on HPPA never reported in update_excuses
> BTW, why this problem manifest itself only on hppa? Is the c++ compiler > somewhat different or is only a chain of #ifdef and/or configure > switches that behaves differently on that arch? In woody, hppa is the only architecture that is using gcc-3.0 compilers. The other architectures are all using 2.x compilers. The "problem" is that there are a lot of broken C++ code out there, and gcc-3.0/libstdc++ is a lot stricter, so many things that used to build will now fail. randolph pgpZT4fzYAJAR.pgp Description: PGP signature
Re: gmetadom failure on HPPA never reported in update_excuses
In reference to a message from Stefano Zacchiroli, dated Apr 07: > I noticed that another package of mine, which is needed to build > gtkmathview, wasn't successfully rebuilt on hppa, namely package > "gmetadom". it needs some c++ work. For one thing it references internal libstdc++ symbols (__STL_BEGIN_NAMESPACE, etc). Instead you should use "namespace std;", etc. You can try building your package on paer.debian.org (when it comes back up) or sarti.debian.org, which are both hppa machines. randolph -- Debian Developer <[EMAIL PROTECTED]> http://www.TauSq.org/ pgpGBM4Pepcxu.pgp Description: PGP signature
Re: pci.ids
> There are several package shipped with a copy of pci.ids with various > version. > (at least pciutils, xviddetect, ksysctrl in testing) > It would be better to have only one such file, and to have an easy > way to update it. With new hardware sold, it become easily outdated, > and it may cause problems when installing the stable Debian release. xviddetect is (should be) gone from testing. it fact, it has been unavailable for woody for quite some time. originally xviddetect used /usr/share/misc/pci.ids, but because not all architectures have pciutils, i decided to ship a copy inside the package to keep it Arch: all randolph -- Debian Developer <[EMAIL PROTECTED]> http://www.TauSq.org/
Re: BUG: #110304
> As stated in bug #110304 deity won't work, this becouse it depends on > libapt-pkg-libc6.2-3-2-3.1 (NOT AVAILABLE) which is (as you can see) > not available. this is not really a deity bug the 0.8.0.5 package was uploaded originally for sparc/hppa/ia64. the i386 autobuilder just hasn't picked it up yet... randolph -- Debian Developer <[EMAIL PROTECTED]> http://www.TauSq.org/ pgp6CxYTSIAmP.pgp Description: PGP signature
Re: A script to see how much a package is depended upon.
> As I anticipated, it has a lot of "loops", and it is going in ridiculous > values. These things should have had trouble when porting to new arches, > but anyway, I have put the script up on > http://mikilab.doshisha.ac.jp/~dancer/analyse-sourcepackages neato i had written something somewhat similar some months back that the ia64/hppa porters occasionally use. It only analyzes build-dependencies though i made a picture of the build-dependencies of bash using the script and graphviz: http://people.debian.org/~tausq/bash-build-deps.png scary... also generates things like http://auric.debian.org/~tausq/buildd/ia64-latest.html but the script is a bit buggy and ugly :) auric:~tausq/bdepvis if anyone is interested. randolph -- Debian Developer <[EMAIL PROTECTED]> http://www.TauSq.org/
Re: build daemon architectures
> The Automatic Package Building System page[1] lists the build > daemons with web pages. It does not list those without, however. > Since my latest libcdaudio packages are considered out of date on > i386, I was wondering if a build daemon exists for that > architecture. If you know of a build daemon for an architecture > other than arm, m68k, powerpc, or sparc (even if it doesn't have a i386, mips, mipsel, ia64, hppa, alpha, s390 all have autobuilders. randolph -- Debian Developer <[EMAIL PROTECTED]> http://www.TauSq.org/
Re: A proposal: un-split perl packages for 5.6.0
> Given that perl generally provides an option for backward compatibility > to a previous release, it would seem that a cleaner alternative is > available. I have prepared a set of non-versioned `perl', `perl-base', > etc. packages for 5.6.0 to demonstrate the proposal: I've been running these for about a week now... they work great. Very good job bod! any word on when these will make it into woody? randolph -- Debian Developer <[EMAIL PROTECTED]> http://www.TauSq.org/
Re: Installed console-apt 0.7.7.2potato1 (source i386)
> What does it mean? console-apt is not in potato and is it put again in > stable? rumours about console-apt taking over the world are greatly exaggerated *cough* randolph -- Debian Developer <[EMAIL PROTECTED]> http://www.TauSq.org/
Re: Packages removed from potato
> Yes, I said to you that I may NMU gnudip, unfortunetaly I haven't found > the time to do so ... well, it's my package, so it's my fault i don't suppose i can get it back in somehow? :/ randolph -- Debian Developer <[EMAIL PROTECTED]> http://www.TauSq.org/
Re: Packages removed from potato
> Package: gnudip (debian/main). > Maintainer: Randolph Chung <[EMAIL PROTECTED]> > 59248 gnudip: Gnudip prerm script fails with error `groupdel: group gnudip > does not exist' ok, some misunderstanding here. someone had said that he was going to do a nmu for me because i've been rather busy with other stuff, but i guess that didn't happen :( randolph -- Debian Developer <[EMAIL PROTECTED]> http://www.TauSq.org/
Re: Idea: Debian Developer Information Center
Hi Raphael, > - information about the NMU policy that the maintainer has adopted > (timeframe before a NMU is allowed, do i need an authorization to do a > nmu ?, ...) easy to add. Jason would be the person to do this (add a field to the db). The web interface can easily be changed to update/view this info. > - the list of packages he's maintaining (yes some maintainer forget > that they're maintaining some packages) with up-to-date statistics for > each package (number of important/normal/wishlist bugs, > standards-version that it does follow, last upload) I actually have some code to do this, but until our bug system is ldapified or at least have a non-textual backend, it will be difficult to do. Ben has a bts ldap setup, but i understand it is not official and not necessarily maintained all the time. > - a link to the personnal bug page the problem with this is that many maintainers have packages registered under different forms of their email address, so this is actually more difficult to do. You will probably need to do something with the pgp/gpg sig on the .dsc files. again, this is something i've looked at in the past, but at that time i was asked to hold off until the bug system has been overhauled. > - any other information that may be suitable for such a page like > the latest news that must be read by Debian developers (think > about debian-devel-announce) Wouldn't this just be a link to the mail archive for that mailing list? randolph -- Debian Developer <[EMAIL PROTECTED]> http://www.TauSq.org/
Re: PDQ?
> There is apparently a printing system out there that is designed to > replace lpr-based ones, called PDQ. I notice this is not yet in > Debian. Is anyone planning to package it? Does anyone have any > experience with it? If so, how do you like it? I had some debs at http://master.debian.org/~tausq/debs/ haven't decided if i want to maintain it though. if anyone is interested, please go ahead and package. randolph -- Debian Developer <[EMAIL PROTECTED]> http://www.TauSq.org/
Re: Danger Will Robinson! Danger!
> IMHO, leaving out 2.4 is a bad idea. there were problems with 2.0 -> 2.2. there are several indications that 2.4 proper won't be out till sometime in the summer. i sure hope potato is out before then... randolph -- Debian Developer <[EMAIL PROTECTED]> http://www.TauSq.org/
Re: login message on lully.debian.org
> > The system has been up for 14 days and /etc/motd was last modified on > > Jan 27. Is it possible that the repairs are complete and someone > > forgot to remove this line from /etc/motd? We are waiting for some hardware to arrive... stay tuned... randolph -- Debian Developer <[EMAIL PROTECTED]> http://www.TauSq.org/
xplanet project - volunteers sought
Have you all seen the nice developers' map at http://www.debian.org/devel/developers.loc ? Here's your chance to help make it better! The map is generated by xplanet. However, we have a few slight problems 1) xplanet doesn't build well on slink (well, xplanet does, but it depends on things that are only in potato). This can be circumvented with a bit of effort 2) more importantly though, xplanet uses imlib, which requires a X display to run. This means that we can't generate the map easily from a non-interactive script (like a crontab or something) Would someone be interested/willing to look at the xplanet code and patch together something that uses, say, libjpeg instead of imlib? Please email me if you are willing to take this one. Thanks! randolph -- Debian Developer <[EMAIL PROTECTED]> http://www.TauSq.org/
Re: Use https://db.debian.org/ [was Re: Add your location ...]
> Apropos redesign: the images on the secure version point to a > non-secure URL and are therefore not rendered. We are looking into this and will try to get it fixed in the next 24 hours. > Paul> Moreover, I tried updating my info on the non-secure page, but > Paul> my postcode is STILL not getting added (it is "7609 JD"; yes, > Paul> with a space), > > Me too, although it is only digits. I will look into this. I had thought it was fixed already, but maybe I'm wrong. > Paul> and also my coordinates (0521952 / 0063753) were not added. > > This worked for me. But I added a "+" in front of each, maybe this is > important. When did you try? The first versions of the scripts required a sign in front. Now (since about three days ago) it shouldn't. randolph -- Debian Developer <[EMAIL PROTECTED]> http://www.TauSq.org/
dependency problems
A few packages in potato seem to have dependency problems at the moment. This is by no means an exhausive list. This is just a general heads-up. I will file bugs with the packages if similar ones have not yet been filed. emacs20: Depends: liblockfile0 but it is not installable Depends: liblockfile0 (>= 0.1-1) but it is not installable libtiff3: Depends: libjpegg6a but it is not installable python-base: Conflicts: python-misc Conflicts: python-net python-misc: Depends: python-base (=1.5.2-5) but 1.5.2-6 is installed python-net: Depends: python-base (= 1.5.2-5) but 1.5.2-6 is installed xpaint: Depends: libjpegg6a but it is not installable randolph -- @..@ http://www.TauSq.org/ () ( >__< ) ^^ ~~ ^^ pgpGQniNS5Pz1.pgp Description: PGP signature
Re: /lib/libNoVersion.so.1
In reference to a message from Russell Coker, dated May 12: > I have just had this file appear on my system. It is a broken link and > "dpkg -S" doesn't tell me anything about it. It appeared when I installed > about a dozen of the latest potato packages yesterday... > > Does anyone know what it is about? sorry, i was wrong... :) it was part of libc6, but doesn't seem to be in newer versions of the deb package. my apologies, randolph -- Debian Developer <[EMAIL PROTECTED]> http://www.TauSq.org/
Re: /lib/libNoVersion.so.1
In reference to a message from Russell Coker, dated May 12: > I have just had this file appear on my system. It is a broken link and > "dpkg -S" doesn't tell me anything about it. It appeared when I installed > about a dozen of the latest potato packages yesterday... > > Does anyone know what it is about? Most likely you installed a package from redhat that is converted with alien. afaik, that's a redhat library, not a part of debian. randolph -- Debian Developer <[EMAIL PROTECTED]> http://www.TauSq.org/
Re: Corel Setup Design Proposal
> That's all fine, but did we ever find out if someone were crazy enough to > pay for the PnP monitor specs (wasn't it $300 or so?) that an > implementation could be done and properly documented source released? > Reverse engineering this just does not sound like fun. From my limited understanding and research, the "PnP monitor specs" belongs to VESA, a more "enlightened" organization than the owner of the rest of the PnP specs :-) The VESA PnD (plug and display) specs can be downloaded from the VESA web site (http://www.vesa.org/pnd.pdf). A cursory flip through the specs seem to indicate that it will indeed provide video timing (as well as other interesting pieces of) information about your display hardware. Is there a different PnP monitor spec that people are talking about? This (the VESA spec) is what my monitor uses. HTH, randolph -- Debian Developer <[EMAIL PROTECTED]> http://www.TauSq.org/ pgpXtvDE1HX6I.pgp Description: PGP signature
