Solicito lista de mails
Como consigo lista de mails de uruguay y/o del mundo? Como te lo pago? Soy de paysandu uruguay
Re: [Re: Orphaned packages?]
> > wmaker-data yours
> > wmaker-usersguideyours
> > wmavgloadJosip Rodin's
> > wmload Josip Rodin's
> > wmmail Josip Rodin's
> > wmmixer Shaleh's
> > wmmount Josip Rodin's
> > wmrack Shaleh's
> > gltt yours
| I'd like to retract my offer for maintaining wmmail - I don't use it nor
| do I like it. I will/have, however, take wm{avgload,load,mount}.
Ok, I'm cc'ing -devel and wnpp. wmmail needs a maintainer.
| I will most probably try wsoundprefs and wsoundserver, though. Is that
| okay with you?
Yes, please. I'm already in Stuttgart, but I don't think I'll get my hands on
a Debian box very soon... I'm in the middle of a Silicon sea :-)
(perhaps it's time to give that MIPS port a second look :)
Thanks,
Marcelo
Get free email and a permanent address at http://www.netaddress.com/?N=1
Re: Ubuntu discussion at planet.debian.org
On Sun, Oct 24, 2004 at 01:37:21AM -0500, Manoj Srivastava wrote:
> > Okay, it's a month old, but there hasn't been any since.
> > http://lists.debian.org/debian-devel-announce/2004/09/msg5.html
> > "We are also still missing official autobuilders for
> > testing-proposed-updates on alpha and mips. All other architectures
> > appear to be keeping up with t-p-u uploads."
>
> Missing a buildd on an arch or too is a far cry from t-p-u
> being unsupported.
Testing is by design all-or-nothing. As long as a single architecture
hasn't buildd support for t-p-u, the buildd support for t-p-u is as
good as missing. You could do builds by hand, but then again, how many
developers actually do that? And it "only" takes a mail to the admin
team ("please install build dependencies for foo in bar").
Marcelo
Re: Package names don't matter too much
On Thu, Oct 07, 2004 at 05:15:30PM +0200, Frank Küster wrote: > There's more to a package name than just being a key to tools. It is > the name by which one remembers the software, even when he or she > doesn't really know it; it is the name one uses when asking a friend > (or Dr. Google) about it. Do you realize that you just argued in favor of naming this CDDB? This _is_ the name of this, ehem... bundle. Go argue with upstream if you don't like their naming convetions. I certainly don't like krap, it sickens me, but I manage to ignore it. > > So this nameing discussion is about what package data should be > > mangled into the package name, in this case especially what > > dependency data. > > You wanted the discussion to be more general - then please > acknowledge that it is not only, or even mainly, about dependencies. > I have learned that I don't need to activate some GNUstep desktop to > use cddb.bundle or terminal.app, so this is no reason to prepend > "gnustep-". For me the easiest method for finding some piece of software for GNOME is this: $ grep-available -s Package -F Depends gtk2 -a -F Description mail Package: rubrica Package: gnome-pilot-conduits Package: gnubiff ... which _is_ about dependencies. What you keep arguing about is something that is better solved at the UI level. > There are more reasons, among them the wish to have names that can > easily be recognized and memorized, and the wish to have a name that, > if it isn't unique, at least makes it possible to distinguish the > program from others: Not only in a technical sense, but in human > language. Yes, that's fine and that's what .app and .bundle are for. Marcelo
Re: Comparing FHS 2.3 and 2.1
On Tue, Oct 26, 2004 at 03:02:02PM -0500, Manoj Srivastava wrote: > 5)== > > User specific configuration files for applications are stored in the > user's home directory in a file that starts with the '.' character (a > "dot file"). If an application needs to create more than one dot file > then they should be placed in a subdirectory with a name starting > with a '.' character, (a "dot directory"). In this case the > configuration files should not start with the '.' character. > > I have no idea if we comply, but this is a new requirement. Holy... and that's the area of FHS... how? First, does every single package have to comply with this? Off the top of my head: * aspell stores user's dictionaries in ~/, and it store several files per languaje. * bash reads and writes a number of files in ~/ (.bash_profile, .bashrc, .bash_history) * there are several directories related to GNOME (at least ~/.gnome2 and ~/.gnome2_private) * vim has ~/.vimrc, ~/.viminfo (configure IIRC), ~/.vim/ * Window Maker stores its configuration across several files and directories under ~/GNUstep (configurable) (and no, I won't change the default because it's configurable via an environment variable) > So, we have a few minor things to tweak (/media, /srv, and the > XF86Config stuff, and then we should be OK to move to FHS 2.3 in > Etch. Isn't the configuration file used by the X.org server called something else? (It's rather silly to hardcode the name of a configuration file used by a specific vendor) Marcelo
Re: apt-proxy v2 and rsync
On Thu, Oct 28, 2004 at 01:54:54PM +0200, Adrian 'Dagurashibanipal' von Bidder wrote: > IIRC the problem is that rsync is quite CPU-heavy on the servers, so > while the mirrors have the (network) resources to feed downloads to > 100s of users, they don't have the (CPU) resources for a few dozen > rsyncs. And shouldn't this be left as a decision for the mirror administrators? It's not like setting up a mirror _automatically_ allows rsync access to it, isn't it? Marcelo
Re: $HOME/.dotfiles and FHS 2.3
On Sat, Oct 30, 2004 at 01:41:23PM +0200, Andreas Rottmann wrote: > Why not simply make it search for ~/GNUstep, and when that isn't > found, ~/.GNUstep or something like that - would retain full > compatibility. With Debian, yes. With the rest of the world, no. You have to take into account to that ~/ is not unusually a shared resource. Marcelo
Re: $HOME/.dotfiles and FHS 2.3 (was: Comparing FHS 2.3 and 2.1)
On Fri, Oct 29, 2004 at 04:53:29PM +0200, Frank Küster wrote:
> > * bash reads and writes a number of files in ~/ (.bash_profile,
> > .bashrc, .bash_history)
> > * there are several directories related to GNOME (at least ~/.gnome2
> > and ~/.gnome2_private)
> > * vim has ~/.vimrc, ~/.viminfo (configure IIRC), ~/.vim/
>
> They should probably use their own directory in the future. I think
> this would really be a good idea.
I don't think so. It's a matter of interoperability. If the guys
writing the FHS don't care about this it's their problem, but I've
worked for many years in environments where my home is shared among
computers with different operating systems (e.g. Linux, IRIX, HP/UX and
Solaris), and the prospect of increasing complexity in order to
accommodate something like the FHS doesn't appeal to me. I _do_ split
things like .bash_profile across several files in ~/.bash/.
Nevertheless I know that bash reads ~/.bashrc; introducing something
that deviates from this on some platforms buys the user little benefit.
By the way, you can get rid of ~/.viminfo by adding n~/.vim/viminfo to
viminfo.
> > * Window Maker stores its configuration across several files and
> > directories under ~/GNUstep (configurable) (and no, I won't change
> > the default because it's configurable via an environment variable)
>
> I was always annoyed by this, and it's not easy to find the solution
> in the documentation (I only learned of the environment variable in
> this thread). Why not change the default, when everybody can get back
> the original buggy behavior by setting an environment variable?
It's in the manual page:
GNUSTEP_USER_ROOT
specifies the initial path for the Defaults
directory. "Defaults/" is appended to this variable to
determine the actual location of the databases. If
the varialbe is not set, it defaults to "~/GNUstep"
patches to improve wording or make it easier to understand (or for that
matter, to add a whole new section to the manpage if you think that's
the solution) are always welcomed.
I guess something like this would work:
if test -z "$GNUSTEP_USER_ROOT" ; then
if test -d "$HOME/GNUstep" ; then
GNUSTEP_USER_ROOT="$HOME/GNUstep"
else
GNUSTEP_USER_ROOT="$HOME/.GNUstep"
fi
but I have the same interoperatibility problem again. This deviates
from the upstream default behaviour.
Marcelo
Re: Alioth Project Denied
On Thu, Nov 04, 2004 at 11:31:09AM -0700, [EMAIL PROTECTED] wrote: > Your project registration for Alioth has been denied. > > Project Full Name: Window Maker Debian Package > Project Unix Name: wmaker > > Reasons for negative decision: > > If you decide to use an alioth project to comaintain a package, you > need to include a "pkg-" prefix in your project name. This is > required to be able to differentiate projects dedicated to Debian > packaging from projects where alioth is the main repository of > "upstream" code. > > Please resubmit your project with a good name. a) I couldn't find a policy in the website b) It's very rude to reply anonymously, someone care to put a name behind this email? c) Can't you just do it yourself? But whatever, I'll jump thru the hoops if that's what it takes. This project is making a custom out of threating developers like crap. Marcelo
Re: Duelling banjos or how a sane community goes crazy
On Mon, Dec 06, 2004 at 08:12:50AM +0100, Andreas Tille wrote: > I failed in ending this thread when I posted > > http://lists.debian.org/debian-devel/2004/12/msg00016.html > > instead I caused two trolls making even more noise. Without having read your post, I'm pretty confident that you failed *because of* Godwin's Law. It is a part of Godwin's Law that calling someone a Nazi (directly or by implication) with the sole purpose of ending a thread *does not* end it. It's a pitty that Godwin's Law has fallen in such a state of misunderstanding. Using the word Nazi does not end a thread. Talking about Nazi or National Sozialismus does not end a thread. References to those concepts do not automatically end a thread. Godwin's Law is about degradation in S/N: a thread will degrade to the point where it's only noise, and reaching this point it dies. Now it's up to you to find out what 'noise' means in this particular case. > I hope all you people are aware that you are causing a new duelling > banjo case and helping out Google to connect Debian with hot-babes. Actually I don't find it that bad. Between slowly fixing stuff in my packages and trying to catch up with several debian mailing lists, the hot-babe thread has proven rather amusing[0]. If two years from now some teen googles for "hot babe" and lands up on Debian's homepage, why is it bad? > 3. Go to debian-curiosity with mails which do not belong to > debian-devel. debian-curiosa is neither a garbage dump nor a place where you can badmouth other people, as some folks seem to think, and the hot-babe thread really has no place there. Marcelo [0] Completely OT: I find it rather hard to beleive that there are people who actually hold some of the opinions that I've read so far. Currently the "Parlament" of my country is discussing the passing of a law which pushines several forms of abuse of women *by* men by not the same forms of abuse of men by women. Ignoring the fact that existing law already refers to and punishes such actions *and* that it goes directly against our Constitution, this particular law has some people rather tickled, including myself: it is hard to beleive that at the dawn of the XXI century, there's still people out there who approach the "gender" problem in this way. You just can't solve a gender problem by creating more differentiation.
Re: dselect survey
On Fri, Dec 10, 2004 at 11:52:05AM +0900, Miles Bader wrote: > Completely and utterly wrong in my case. I'm exactly the sort of > person that you apparently think should like dselect, but I think > aptitude is _far_ superior, for both experts and newbies. The > competition isn't even close. Except when you face the fact that aptitude uses a very sick kind of MDI. Sick because there's actually no "MD", you're editing a single chunk of information using multiple views. It's very hard to figure out "what just happened" because there's no direct visual feedback. The other problem with aptitude is touted as a design feature: it tends to be all-or-nothing. Either you use it always or you don't (automatic removal thingie). This becomes a problem when multiple persons use different interfaces for adding and removing packages to the system. Marcelo
Re: dselect survey
On Wed, Dec 15, 2004 at 10:20:09AM +0900, Miles Bader wrote: > > The other problem with aptitude is touted as a design feature: it > > tends to be all-or-nothing. Either you use it always or you don't > > (automatic removal thingie). This becomes a problem when multiple > > persons use different interfaces for adding and removing packages > > to the system. > > You exaggerate. I do not. I've seen aptitude remove "unwanted" packages more than a couple of times because of this. It's a cool feature, yes. It's also a design bug. Marcelo
Re: LCC and blobs
On Sun, Jan 02, 2005 at 01:27:21AM +0100, Måns Rullgård wrote: > Some Alpha systems (I forgot which) came with only the inferior > AlphaBIOS installed in flash. Later, an SRM version for this system > was released, and installing this is generally considered a good > thing. These firmwares required different boot loaders, and > different kernel configurations, so a boot loader or kernel package > could reasonably have some sort of dependency on one of the > firmwares. Stretching that line of thinking, a VGA driver "depends" on a card with a VGA BIOS. And I had once a card with a flashable VGA BIOS. And I had to flash it once because the Linux driver wouldn't work with the older one (anymore IIRC)... Unless you are saying that you have to reload the firmware each time you boot the machine (and I know you aren't because I had one of those at some point), I hope that you can understand that you have to modify the machine in order to use a particular piece of software, because that particular piece of software requires that particular machine. IOW, we could can the entire port because it depends on present on machine , being a BIOS, a certain chipset, a certain controller, a certain graphics card, or whatever else you wish. Darn! That's all of them. IMO we have to draw the line at some point that's *useful* and *practical*. Committing suicide is neither of those. I think the proposal that spawned this subthread is both. Marcelo
Re: New stable version after Sarge
On Tue, Jan 04, 2005 at 03:41:41PM +0100, Christoph Berg wrote: > ...which Debian provides for its stable distribution at any time, > even if the last stable release was ages ago. How does a fixed > release date help there? Besides Florian's point, you have to consider that Debian needs people actually testing what's going to be released. And many of the people doing the testing, are doing it because they want to have something reliable that they can use at their "work"place (however "work" is defined here). But at some point they just can't take that "let's use a Desktop environment which is two years old and has significant usability bugs which were fixed a year ago" anymore and they go away. So Debian hurts itself at the end of the day. So, no, a fixed date doesn't help. A release schedule does. (And no "we will release in two years time" is not a release schedule in this context). Marcelo
Re: New stable version after Sarge
On Tue, Jan 04, 2005 at 10:35:37PM +, Matthew Garrett wrote: > It shouldn't be forgotten that the biggest blocker after these things > is probably a general failure to actually care all that much. How > many people are actually behaving as if a release is just around the > corner? How can we fix this? Talk to your leader. He's a "persons" person (I recall some talk about motivating people and stuff like like during the elections). No, I don't really mean that seriously. At least not the part about going to talk to Martin. It's a motivation problem. Simple as that. There's no cohesion. I have the feeling there's too much "behind the scenes" talking taking place. This mailing list is not even the shadow of what it used to be. There are hardly any really technical discussions taking place here. I doubt someone can actually *learn* something from following d-d anymore[0]. That means this mailing list has become somewhat a burden, not something you can enjoy, which is the cornerstone of volunteer work. A release is a big motivation boost: it's something you can see, something you can point people to. Ride on that wave. Debian's problem, seen from the inside (you don't have to give a damn about what the Slashdot crowd says), is that we let that wave break, and there isn't another one coming behind it. Marcelo [0] Besides learning that there is still people in this world who seem to think that feminism is actually a solution to something. I am still amazed by that one.
Re: New stable version after Sarge
On Tue, Jan 04, 2005 at 03:34:20PM +0100, Martin Schulze wrote: > > One of the biggest disadvantages of Debian for me is the long time > > it takes for a new stable version. > > > > What about saying something like: the next stable release comes in > > the beginning of 2006? > > The release date for a Debian release is not set by a calendar but by > quality. At least that's been the case including sarge. Hence, such > a sentence would not mean anything. Then let's accept the premise behind the whole testing idea and target Sarge+1 for Sarge+6 months. Or does the team have plan that will stall that release for another year? > What if the installer is broken at that time? debian-installer is good as it is now. Sarge+6 months should be able to use more or less the same installer, plus new drivers. And a cursory look at the debian installer code gives me the impression that adding new drivers should be relatively easy. > What if the buildd network is busted at that time? Well, I surely hope the buildd network won't be busted for x time (where x is much larger than a couple of weeks). Do you have something concrete in mind (like, say, one half of an arch builders bailing out because people can't seem to talk to each other or something like that?) > What if n library transitions are in progress at that time? Well... according to the testing delus^Widea, this should not happen. Or, if it happens, it should be not so difficult to handle... Oh... hi, reality... nice to make your acquaintance. > What if our archive suite lacks an important improvement which is a > requirement for being able to maintain the new stable release? Come on. This one really feels like a cheap excuse. First, are any such important-can't-wait-a-second-longer improvements scheduled? Second, there's such a thing as testing. No, not that part of the archive. Real testing. Calling for people to upload real packages to a testing archive. Doing real work with the testing archive. Bouncing real uploads from the real archive to the testing archive. Such things. Third, there's also planning ahead. If Bar wants to absolutely have that important improvement before sarge+1, Bar should allot something like 3-4 *months* before the target release date for the in-archive testing phase and be ready to commit some time for urgent fixes. If that can't be done because all this is volunteer work and all those things (that I can fully relate to and I'm not downplaying one iota!), then sorry, we can't have that important improvement. IOW, don't stall the whole project because of your pet peeve. > Sure, you could still release, but would you really like to have such > a release? I would like to get rid of the "Debian can't make timely releases" and "Debian stable is a bunch of out-of-date software" stigmas. In fewer words: I want to have the cake and eat it, too. Debian stable without the 2 year lapsus in between. > What if security support for a new release cannot be guaranteed at > that time? That is a show stopper. "We did our best, but we can't release Debian Sarge+1 at this time. New target date for release: ..." If you give people a target to work with, with enough time (and "enough" has to take into consideration that Debian is still mostly put together by volunteers), people can plan ahead. The current chaos does not give *developers* this. And users get frustrated each time they see a Debian 3.0rX come out, but no sarge in sight. I do get your point and I'm not saying that it is easy (or even possible!) to stick to a faster release schedule, but refusing it upfromt without trying does not help. Marcelo
Re: New stable version after Sarge
On Tue, Jan 04, 2005 at 11:25:29PM +, Jonathan McDowell wrote: > We've spent most of the past year thinking a release might be just > round the corner. We can only cry wolf so many times before the world > stops believing us and finds an option that actually works. You ought to hear the jokes I get to hear once a month on the local LUG meetings. Oh dear, next meeting is this saturday. Marcelo
Re: New stable version after Sarge
On Fri, Jan 07, 2005 at 12:50:04AM -0800, Steve Langasek wrote: > Yes, I don't think the release team has any intention of working > itself ragged to get a second release out 6 months after sarge. I > also don't think there's any consensus among developers (or users) > that we *want* to release Debian that frequently. Well, the development model in Linux (Free Software, OSS, whatever) is such that new hardware is supported in new releases. A commercial OS vendor does introduce support for newer hardware in older releases of their OS (I remember several cases of this on IRIX for example) via patch revisions or point releases or whatever they might want to call that. But this is a time-consuming task and most upstreams prefer to just release a new version. This is not always true of the kernel, that's right, but it's common in XFree86 and I have to assume that it's also the case for X.org. It's also true of things like GPhoto, or Gimp Print. Upstream does not want to waste time doing point releases of older software. People might argue that you "just" need to shift the load to the Debian maintainer. For security updates, yes, I can agree with that, but for "normal" updates, no, sorry. That means I do think that *users* have some interest in this kind of thing. Backports.org? No, that doesn't cut it. It's got to be officially supported by a release and on the install CD. Branching stable for this purpose (just like security updates) is not an option IMO. I don't think we have the manpower for this. > A 6-month period honestly doesn't allow us much time for new > development anyway. It depends on what you call development. Are you thinking of " has a release cycle that's not compatible with a 6 month release period"? Say GNOME or KDE? Well, gets in the next release. So simple. We are known for missing upstream releases by a hair (sarge is almost certainly going to miss the next upgrade to GNOME, perhaps to KDE, it's already missing X.org, gcc 3.4 is subject to debate) so this wouldn't put us in a worse situation than now. Are you thinking of say, the installer? I certainly *hope* that the installer is going to stay in the current status for at least another release! Another "whoos, let us restart from scratch" won't be welcome by anyone. And my hope is based on the fact that the new installer is *good* (instead of just adequate, like b-f). Or is it the next big thing going on with the archive? We don't have to go from X.0 to (X+1).0 in 6 months. It's perfectly ok to go from X.0 to X.1. > If all we wanted was a point release of sarge, that'd be fine; but I > think most people would like to see etch be an improvement over sarge > in more respects than just hardware driver count, and we have to be > realistic that this means a period of heavy changes followed by a > period to stabilize everything again. And *that* was our mistake with sarge. By introducing *many* heavy changes we burned ourselves out. These changes are very welcome, don't get me wrong. But I say it again: this is pushing our testing users away. Thanks to broadband there are many who are happy with "testing", but let's face it: for a very long time, it was a major risk to use testing and it had a _load_ of software that was either buggy or suboptimal, and the fixes were already present in unstable for a long time. I dumped testing on the machine I used to use on a daily basis around 2002 because it was a pain. Some people say this has improved since then, but if the kind of big changes that stalled testing back then happen again, well, it's back to square one. Ok, 6 months may be too fast for some people (and I still want to know about concrete examples where this is true and why), how about 9 months? How about 1 year? My point is: set a goal and try to accomplish it. Marcelo
Re: New stable version after Sarge
On Sat, Jan 08, 2005 at 12:46:00PM -0500, William Ballard wrote: > On Fri, Jan 07, 2005 at 08:22:47PM -0600, Marcelo E. Magallon wrote: > > We don't have to go from X.0 to (X+1).0 in 6 months. It's > > perfectly ok to go from X.0 to X.1. > > .1 Releases aren't for adding functionality which was created after > the .0 release. It's for finishing the stuff you postponed doing so > you could ship. Well, traditionally we've never decided before hand that the next release is going to be 4.0 or 3.2 or the like. We work on whatever comes our way, and when it's ready someone decides if it's 4.0 or just 3.2. Some people are of course feel strongly about calling the next thing 3.2 and others would rather see 4.0 -- because got in -- even if Debian as a system isn't seeing any big leap. Since we try not to develop software ourselves it is sometimes hard to assess what makes a major release and what a minor one. Marcelo
Re: non-ftp way to upload packages
On Tue, Feb 01, 2005 at 04:12:16PM +0100, Bartosz Fenski aka fEnIo wrote:
> Anyway, your mail also says that if someone send you config for
> dupload then you are going to include it in some README. Is this
> README available somewhere?
Something along the lines of the following in ~/.dupload.conf
package config;
$default_host = "d0";
$cfg{'defaults'} = {
login => exists $ENV{DEBUSER} ? $ENV{DEBUSER} : $ENV{USER},
method => "scpb",
dinstall_runs => 1,
};
$cfg{master} = {
fqdn => "master",
incoming => "/home/Debian/ftp/private/project/Incoming/",
};
$cfg{d0} = {
fqdn => "gluck",
incoming => "~tfheen/DELAYED/0-day",
dinstall_runs => 0,
};
foreach (1 .. 9)
{
$cfg{"d$_"} = { %{$cfg{d0}} };
$cfg{"d$_"}{incoming} =~ s/0(?=-day)/$_/;
}
foreach my $t (keys %cfg)
{
foreach my $d (keys %{$cfg{'defaults'}})
{
$cfg{$t}{$d} = $cfg{'defaults'}{$d} unless exists $cfg{$t}{$d};
}
}
1;
I made this up on the spot, you can keep it if it breaks.
Marcelo
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: list what's in the NEW queue?
On Wed, Feb 02, 2005 at 06:28:58PM +0100, Jeroen van Wolffelaar wrote: > As a DD, you can ls /org/ftp.debian.org/queue/new on merkel, daily > synced. Beware, there are 2826 files in there atm, so ls via grep or > something. And while we are on the subject, what's with NEW not being processed? Or are we again in the usual "I'll process any package that I feel like processing" situation? Marcelo PS: "blah, blup, release, blah, sarge" ... spare it, *please*. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: list what's in the NEW queue?
On Thu, Feb 03, 2005 at 08:39:10PM +0100, Joerg Jaspert wrote: > It works and is available from dak.ganneff.de. And the packages is > used on several archives now. Its just not out of NEW atm. So, let's *guess* ... * ftp-master surely knows about the license on that one, so it's not a "*I* don't like the license" issue * it's not a "fetch me pr0n!" package, no problem there * it's not ftp-master's business to judge on _technical_ merits of the pacakge (bad packaging practices, missing dependencies, ignores /chapter and verse/ of policy, ...), so we can safely rule that one out * ftp-master hasn't got the time atm (where "m" ~ "at least 2 months", AFAICT)... we have this thing called debian-devel-announce, you know? * -release decided to stop processing NEW ... we still have this thing called debian-devel-announce, you know? Did I miss a memo? Marcelo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: list what's in the NEW queue?
On Fri, Feb 04, 2005 at 11:21:02AM +1000, Anthony Towns wrote:
> >On Thu, Feb 03, 2005 at 08:39:10PM +0100, Joerg Jaspert wrote:
> > * it's not ftp-master's business to judge on _technical_ merits of the
> > pacakge (bad packaging practices, missing dependencies, ignores
> > /chapter and verse/ of policy, ...), so we can safely rule that one
> > out
>
> Uh, wtf are you on?
Anthony, please, think in context. Use some common sense.
I'm not talking about stupid mistakes, ok?
I'm not talking about plain idiotic either.
Or is it now your intention to burden the bunch of people who actually
do some work as ftp-master with package nitpicking, too? Give me a
break.
Let me use a package of mine as an example: mesa 6.2.1-1 (source)
produces, among others, the binary package mesag3. This package ships
libGL.so.1. This is a violation of 8.1 ("The run-time shared library
needs to be placed in a package called `'
[...]"). So, is ftp-master going to prevent this package from entering
the archive because of this? Guess what? There's a reason for me not
following policy in this case. And I've been not following it for
several years and across several releases now.
Better?
Marcelo
PS: And just to answer your question, I get the impression that I'm
"on" stuff much milder than you usually are, coffee being the
strongest, and tea the usual.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debug packages cluttering the archive
On Sun, Feb 06, 2005 at 01:14:09AM -0500, Glenn Maynard wrote: > (Aha: the strip tool mentioned is in elfutils, which is non-free. > Blah.) objcopy(1): --only-keep-debug Strip a file, removing any sections that would be stripped by --strip-debug and leaving the debugging sections. The intention is that this option will be used in conjunction with --add-gnu-debuglink to create a two part executable. One a stripped binary which will occupy less space in RAM and in a dis- tribution and the second a debugging information file which is only needed if debugging abilities are required. The suggested proce- dure to create these files is as follows: 1. "foo" then... 1. create a file containing the debugging info. 1. stripped executable. 1. to add a link to the debugging info into the stripped exe- cutable. Note - the choice of ".dbg" as an extension for the debug info file is arbitrary. Also the "--only-keep-debug" step is optional. You could instead do this: 1. 1. 1. 1. ie the file pointed to by the --add-gnu-debuglink can be the full executable. It does not have to be a file created by the --only-keep-debug switch. -- Marcelo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: list what's in the NEW queue?
On Fri, Feb 04, 2005 at 12:40:02AM -0800, Steve Langasek wrote: > > > It works and is available from dak.ganneff.de. And the packages > > > is used on several archives now. Its just not out of NEW atm. > > > So, let's *guess* ... > > > * -release decided to stop processing NEW ... we still have this thing > >called debian-devel-announce, you know? > > Er, as flattering as it might be to suppose that the release team can > unilaterally decide to stop NEW processing, it's at least as > insulting to presume that we wouldn't have told people about it via > debian-devel-announce, y'know? Whilst no insult was meant, it _still_ _looks like_ a silent decision. My apologies if insult was taken, Marcelo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: list what's in the NEW queue?
Hi,
pardon me for the delay, I really have better things to do that getting
involved all day long in discussions with purposely obtuse people.
On Fri, Feb 04, 2005 at 01:30:22PM +1000, Anthony Towns wrote:
> Marcelo E. Magallon wrote:
> >On Fri, Feb 04, 2005 at 11:21:02AM +1000, Anthony Towns wrote:
> >
> > > >On Thu, Feb 03, 2005 at 08:39:10PM +0100, Joerg Jaspert wrote:
> > > > * it's not ftp-master's business to judge on _technical_ merits
> > > > of the pacakge (bad packaging practices, missing
> > > > dependencies, ignores /chapter and verse/ of policy, ...), so
> > > > we can safely rule that one out
> > > Uh, wtf are you on?
> > Anthony, please, think in context. Use some common sense.
>
> Ah, arrogance and self-righteousness with a dash of utter ignorance.
> Fair enough.
And there goes your typical MO on mailing lists _again_.
Shall I remind you that *you* are the one that recently put a request
for more civil and productive discussions down in written form in front
of the whole project? Please, by all means, do as you say. I'll be
delighted to follow suit.
> > Or is it now your intention to burden the bunch of people who
> > actually do some work as ftp-master with package nitpicking, too?
> > Give me a break.
>
> Dude, you have no idea what you're talking about.
Maybe, I sit on the wrong side of ftp-master, it's been always like
that and I have no intention whatsoever to change that because I'm not
afraid to admit that I don't have the resources to volunteer for such a
task.
That doesn't make my own appreciation of the situation wrong.
> Processing of NEW packages is done with a tool called "lisa", the use
> of which involves two steps -- checking the package, then either
> accepting it, rejecting it, or skipping it. Checking it invokes a
> library called "fernanda.py" whose _sole_ purpose is finding
> technical issues with the package; it runs both lintian and linda,
> gives a full manifest of the changed packages, lists the contents of
> the control file, highlighting issues that might need attention,
> dumps the copyright file, and so on.
Pretty tale.
Useless, too.
A certain truly new, not previously on the archive, package with
*obvious* technical flaws recently sat on NEW for a period a bit shy of
two weeks, and after this time certainly devoted to careful scrutiny it
just made its way into unstable. The problem here is that the flaws
are obvious to anyone with a clue about the package, which I simply
won't require ftp-master to have because it is not their task nor
place.
In the meantime, there's plenty of packages _already_ in the archive
which were split, reorganized or simply added new components, either
because upstream includes more stuff, a bug requires this action to be
taken, policy requires this action or the maintainer simply realized
that -- in three years time, or whenever sarge+1 actually releases
unless something changes drastically in this project -- there will be a
better upgrade path in that way.
What you are saying reads to me as if stuff that already in the archive
gets more attention and demands more time than stuff that's plain new.
The situation wouldn't be this bad if all these "issues that need
attention" would end up in the developer's mailbox and a public mailing
list. But since ftp-master take the actions you mention and says
*nothing* to the involved parties (which in this case happen to be "the
whole project"). I can't honestly image that there's no communication
among ftp-master members: "I'm looking at that", "I don't like that",
"that gives me the willies", ... because you have to _somehow_ avoid
stepping on each other's toes.
Now, *please*, shed some your wisdom and knowledge on me once again and
do tell me where's the problem with sharing this data with the rest of
the project.
And just to save you some detective work: yes, there's a package of
mine sitting in NEW, it's mesa. It's been there for over two months.
I'd be complaining the same if it wasn't there because this has
happened before and it has happened in other areas of the project,
perhaps most notably with the new maintainer queue and the keyring.
> > Let me use a package of mine as an example: mesa 6.2.1-1 (source)
> > produces, among others, the binary package mesag3. This package
> > ships libGL.so.1. This is a violation of 8.1 ("The run-time shared
> > library needs to be placed in a package called
> > `' [...]").
>
> *shrug* The proper thing to do when policy recommends something
> that'
Re: list what's in the NEW queue?
On Fri, Feb 04, 2005 at 03:17:51AM +0100, Wouter van Heyst wrote: > On Thu, Feb 03, 2005 at 06:03:04PM -0600, Marcelo E. Magallon wrote: > > * it's not ftp-master's business to judge on _technical_ merits of > >the pacakge (bad packaging practices, missing dependencies, > >ignores /chapter and verse/ of policy, ...), so we can safely > >rule that one out > > I had the impression this was an important part of the job. While it's true that there _are_ automated tests for some (important!) parts of policy, I really do _not_ want ftp-master installing and deinstalling a bunch of stuff in order to tell me that Foo needs to depend on Bar. I also do not want ftp-master to waste time questioning why libfoo-perl does not depend on libfoo1 perl (which would be easy to catch and also a mistake to fix -- yes, I'm thinking about one very particular example of something still stuck in NEW last time I looked) Have ftp-master question copyrights where -legal already reached a (positive!) consensus if that gives them joy... but have them say something! Again, I'm really not talking about plain silly and stupid. I would have thought that was obvious. Marcelo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Future security problem (was Re: be careful with Replaces, please)
On Mon, 1 Dec 1997, Christian Schwarz wrote:
> The default keyring would probably be the developers keyring. The
> sysadmin could then add new keys of persons/organziations which he/she
> trusts to that keyring.
> Comments?
Err... yes.
Am I the only one seeing a bit of a problem here? (Or am I missing
something I should know?) That is, PGP is non-US. To be able to put PGP
in the main distribution, the master FTP site has to be moved off the US.
I don't have a problem with that, as I don't live in the US, but I
understand this can be quite an annoyance for many people.
Unless of course, the code that *checks* the PGP signatures can be put
into the main distribution, which I think is possible, since what funny US
laws forbid is the export of encryption technologies -- or something like
that -- and PGP signature *checking* doesn't fall into this category,
AFAIK.
As an aftertought... I realized this problem existed a few months ago when
I almost trashed a system I was trying to build a package on... basically,
I did something really stupid in a preinst script, and in fact, that's the
reason I'm using deb-make now. It protects me from myself ;-) (no, really,
I want to learn package building, and it's easier to figure out the
not-so-obvious-right-now problems this way)
Marcelo Magallón
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] .
Trouble? e-mail to [EMAIL PROTECTED] .
Re: pentium specific packages
On Sun, 7 Dec 1997, Brandon Mitchell wrote:
> How about a binary-pent directory with symlinks back to binary-i386 until
> a package is uploaded. Then we need to tell dselect(ftp) to get the
> packages from binary-pent instead of binary-i386.
it's the obvious way... create another architecture tree, binary-i586
(gosh, that going to hit hard on the mirror eventually. Time to get yet
another harddisk for the Debian mirror ;) It's just a minor (I hope)
modification to dpkg:
$ dpkg --print-architecture
i386
$ dpkg --print-gnu-build-architecture
i486
$ dpkg --print-installation-architecture
i386
> Is there an easy way to do this? (Also, if pentium clones also work
> with the ecgs compiled packages, maybe i586 is better than pent.)
I think it should be i586, although I'm not clear if ecgs supports Kx et
al. It should...
Marcelo
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] .
Trouble? e-mail to [EMAIL PROTECTED] .
Re: Where's the SCSI support in Debian?
On Mon, 8 Dec 1997, Andreas Jellinghaus wrote: > at the time bo was released, the options for the kernel were 2.0.29 and > 2.0.30. as 2.0.30 turned out to be unstable on some machines, debian > decided to use the 2.0.29 kernel. the only problem is : > buslogic flashpoint support started with 2.0.30 :-( Does that mean that Debian cann't be installed "easily" on a machine with a Buslogic FlashPoint PT and no IDE disks? I'm going to buy a SCSI adapter to replace the old AHA-1542CF I have right now, and based on a recommendation on debian-user I'm going for the FlashPoint... and I think many people on that list may be influenced by that recommendation, too. Is this going to change soon... I mean, 2.0 is still months away, and it kind of scares me to think of many users facing "way till 2.0" Marcelo -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Semi-important: tearing my hair out over libgtk problems
On 15 Dec 1997, Ben Gertzfield wrote: > libgtk *compiles* fine, but when I run a program that uses it, the > fields where you enter text into only display bizarre characters -- > which change from version to version. For instance, when trying to get > gtk+971201 to work, I only got blank characters when typing. When trying > gtk+971208, I only got capital Os with umlauts. When trying the latest > gtk+, 0.99.0, I only get capital As with umlauts. I tried the latest > version from their CVS repositories and only get lower-case 'x's. I gave up on 971208... funny thing is I also got Ö's. > Other Debian folks have run into this when compiling libgtk, and this > has happened to me now on *three* separate Debian-running computers, > so I don't think it's a hardware problem. Not it's definitely not. I thought it could be the extension to get iso-8859-1 characters. I tryed every combination available on the configure script, but no luck. > I'm 100 percent up-to-date with hamm. I've tried libc 2.0.5c. I've > tried 2.0.6pre3. I've tried 2.0.6pre4. I've tried re-working my > debian/rules (which worked fine with gtk+971109) to use the make > install provided in the gtk+ Makefile along with debhelper instead of > my semi-kluged bash-package-style moving files into separate > debian/tmp-blah directories. I even compiled and installed it straight from the distribution... > Can anyone else try compiling with the .dsc/.diff.gz/.orig.tar.gz at > http://everybody.got.net/~che/gtk/ for me, and see if I'm just nuts? > > I've been struggling with this for *weeks* now. I didn't try that hard... but I got the same problems. I tried just after you pointed out the problem when I asked in debian-user. The last known-to-work version was somewhere arround late november, I can't recall which one. I hoped I could find time the last weekend to go thru the diffs between those two versions, but they are not trivial. In the office next door, a guy has a much hated (by me -- open mindness and all ;) RH box, I think it is 4.2. I was asked him to compile the thing and see what happens (to check which and what library is the problem against), but he's a little paranoid and won't do it. I'll see if I can get something tonight. Can you ask in the gtk list, where it seems to work for most people according to you, which libraries and what versions are they using? (a listing from */lib and /etc/ld.conf would help, I think) later, Marcelo -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: New required base packages for Amiga, Atari, ... detection
On 17 Dec 1997, Brederlow wrote: > Roman Hodek <[EMAIL PROTECTED]> writes: > > > There are now some packages for m68k that make sense only on a > > specific machine type. > > What about the packages that are arch-all that can be installed on any > arch but only make sense on one or two architectures. This sounds exactly the same as the i386 vs Pentium thing. It's the name BASE architecture but different... implementations? One solution could be creating more distributions, like binary-i586, binary-atari, binary-amiga, and simlink shared files from, e.g., binary-i586 back to binary-i386. This complicates things a bit, since a i386 package has to get an entry on i586, just like an all package gets and entry on all the architectures, but only if a i586 specific package isn't already there. I think it would be the same with the m68k stuff. The alphas won't be as easy, I think. For the "not really arch-all" part... could overrides be used/extended for this? Like in "the package says it's arch-all but it's really just arch-i386 and arch-sparc" In the particular case of i586, if done carefully, this wouldn't impact mirrors much. (Carefully = don't just compile i586 optimized code because it's possible) Marcelo. -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: IconPath, menu
On Sun, 21 Dec 1997, Adam P. Harris wrote: > [You (Karl M. Hegbloom)] > > I've created a directory "/usr/X11R6/icons" for my own use. > > We already have the location, and it is standard: > /usr/X11R6/include/X11/pixmaps/ > There are over 300 pixmaps in there, a good deal of which are icons. Is that policy? Gnome puts the pixmaps in /usr/share/pixmaps, and according to my interpretation of FSSTD/FHS, gnome's practice is better. Marcelo -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Intend to take over wmaker, application?
-BEGIN PGP SIGNED MESSAGE- Hi, my name is Marcelo Magallón, and I'd like to take over the maintainance of wmaker, since there are several bugs against wmaker, in particular a mixed dependencies bug. I have tried to contact the current maintainer, Neil A. Rubin <[EMAIL PROTECTED]>, but he doesn't seem to be at that email anymore. I have several local packages for WindowMaker: libproplist0_0.7.1-1_i386.deb wmaker_0.12.3-0.1_i386.deb (*) wmaker-data_0.1_all.deb libwmaker0_0.12.3-0.1_i386.deb libwmaker0-dev_0.12.3-0.1_i386.deb libwraster0_0.12.3-0.1_i386.deb libwraster0-dev_0.12.3-0.1_i386.deb (*) not finished yet. The wmaker package closes all bugs filed agaisnt Neil's package. A couple of weeks ago I sent an application to [EMAIL PROTECTED], but I haven't received an answer yet. I maintain ftp://simula.efis.ucr.ac.cr/pub/debian, and I already have accounts on master, mmagallo, and mmagallM, but my PGP key is not in the keyring. As a side note, Neil also maintains AfterStep, but I don't want to maintain that. If anybody is interested, and Neil is really no longer maintaining it, it may be worth for somebody to take over it, since WindowMaker and AfterStep, along with Enlightenment seem to be pretty popular among Linux folks, according to a recent poll on Slashdot.org, (population sample over 1000) Marcelo. -BEGIN PGP SIGNATURE- Version: 2.6.3ia Charset: latin1 iQCVAwUBNKaqUi1VRe/SjlvlAQHp3QQApHAkumzvHsi9qfe6qDsuauFzEEC2NsJ9 duxyrPg3y0jCI9hT/apN2xo0/AzQx/uxYrs9MRrKcReqRLgz6JjWoYRa6t8fb78P KGOIdbzRMKpN1N5Gzz9Fn9H8CXHBYfNDEV3DH0Kny3OxR8iUi0DnleH4SLxeBtQj ZbBkoyxGzjI= =iJwp -END PGP SIGNATURE- -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Intend to take over wmaker, application?
On Sun, 28 Dec 1997, Joey Hess wrote: > He's only been out of touch since 31 august. That's not too long in > real world terms, esp. if he got hit hard by finals and then went on > winter break. Being a student myself, I quite understand his situation. > However, you might want to consider just doing non-maintainer releases > for a few months At some point I thought that would be the nicer thing to do. In fact the packages I've just uploaded to a local ftp server carry a version 0.12.3-0.1. The maintainer field has my name 'cause I don't want to mix things up and have ppl complaining to Neil because of my mistakes. To make this a proper non-maintainer release I have to change that back to "Neil ...", right? If I ever upload this to master, I'll do that. > in case he shows up again, and spend some more time hunting him down > and finding out if he wants to keep maintaining it. I'll try to get in contact with him. > I'd be happy to try any/all of these if you put them up for ftp someplace. They are on: http://www.efis.ucr.ac.cr/~mmagallo/debian/wmaker ftp://simula.efis.ucr.ac.cr/pub/users/mmagallo/debian/wmaker To get the WindowMaker package going you'll need wmaker_0.12.3-0.1_i386.deb libwraster0_0.12.3-0.1_i386.deb libproplist0_0.7.1-1_i386.deb and you may want wmaker-data_0.1_all.deb, too. Those are GPLed pixmaps. Right now the wmaker package doesn't include any, not even the GNUstep logo. The dependencies for wmaker are: Depends: libc6, libjpegg6a, libpng0g, libproplist0, libtiff3g, libwraster0 (>= 0.12.3-0.1), xlib6g (>= 3.3-5), xpm4g (>= 3.4j-0), zlib1g, cpp I've tested this version for a couple of weeks, and it works for me. I've been fine tunning the package, and it's usable now ;-) Be sure to read README.debian (Ok, ok, I have to work on the documentation) Marcelo. -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Libc6 progress: 1998-01-07
On Thu, 8 Jan 1998, Gregor Hoffleit wrote: > Neil A. Rubin <[EMAIL PROTECTED]>: > wmaker-0.6.3-1 (Mixed dependencies) > > Marcelo E. Magallon <[EMAIL PROTECTED]> is working on > WindowMaker packages based on wmaker-0.12.3. Yes. I have them ready, and some ppl have tested them. (I haven't been able to test the upgrade from 0.6.3-1 -> 0.12.3, yet). I'm just waiting for my PGP key to be incorporated into the key-ring. Marcelo -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: interactive sound configuration utility
On Fri, 9 Jan 1998, Hamish Moffatt wrote: > Redhat have a sndconfig to go with the modularization patches > (which they sponsored according to their web site). The latest > sources were only in RPM format, the tar.gz was old, but I managed > to battle with rpm long enough to extract them. (Conspiracy > theories anyone?) rpm2cpio something.src.rpm | cpio -i works for me. The sources are compiled with a newt version that is NOT 0.10; there are tons of functions not present in 0.10, I don't know if their's newer, older or plain different. Their sound configuration thing is not that amazing. The patches that modulize sound are there, and seem to be a good thing, but documentation is lacking. Marcelo -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Libc6 progress: 1998-01-07
On Fri, 9 Jan 1998, Joel Rosdahl wrote: > > Neil A. Rubin <[EMAIL PROTECTED]>: > > afterstep-1.0-5 (Mixed dependencies) > > It seems that Neil hasn't worked on this package in about four months, > so I'm preparing a non-maintainer release which should fix at least > the mixed dependencies and bug #15395 (chmod a+x > /etc/menu-methods/afterstep). I'll upload it soon if noone complains. I have already done that. It's not 0.6.3 but 0.12.3. This closes all the bugs filed against wmaker; I'm uploading the packages right this minute, but it's going pretty slow. Anyway, I hope the packages get to master before the day's over... ;-) I've tried to contact Neil about this, but I have had no luck. Marcelo. -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Libc6 progress: 1998-01-07
On Sat, 10 Jan 1998, Joel Rosdahl wrote: > > I have already done that. It's not 0.6.3 but 0.12.3. This [...] > > Well, that's great! But what I intend to fix is afterstep, not > wmaker... ;) Oops... I read way too fast... Then both packages are fixed! :-) Marcelo -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
sp upgrade, HTML 4.0, libtool
I haven't seen Susan Kleinmann arround for some time. If nobody objects, I'd like to make a non maintainer upgrade of sp. There's a new version, and it's requiered to parse the W3C Recommendation regarding HTML 4.0. I have packaged the HTML 4.0 DTD and documentation, and I'd like to upload that, too. There's also an upgrade for libtool, that fixes a couple of annoying things about 1.0c. It's version 1.0h, but the GNU people have a big warning about it being alpha software (1.0c is alpha, too, I think). Is this ok for hamm, or is it better to put it in experimental? Marcelo -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: HTTP site list
[I have tons on old mail to read, but it seems something's going on here ;-)] On Sat, 4 Apr 1998, Jason Gunthorpe wrote: > This is a partial list of http enabled mirrors, I did the US and UK. > There are 13 sites listed here. If someone would like to go through the > rest of the mirror list then please do :> I just downloaded apt, and I haven't read the docs, but I'm guessing this is the correct format. Could you please add to /etc/sites.list (was that the name?) # <[EMAIL PROTECTED]> deb http://www.efis.ucr.ac.cr/debian stable main contrib non-free deb http://www.efis.ucr.ac.cr/debian unstable main contrib non-free deb http://www.efis.ucr.ac.cr/debian/non-US stable main contrib non-free deb http://www.efis.ucr.ac.cr/debian/non-US unstable main contrib non-free -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: sleep contains crypto stuff?
On Sat, 11 Apr 1998, Martin Schulze wrote:
> Apart from that, I thought that gcc and tools are intelligent
> enough to only link routines and libraries to executables if
> there are routines from them used.
They are not. I pointed this out on debian-policy a while ago,
but nobody seemed to care. :-(
Marcelo
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Is the BTS working properly?
I have bugs on "my" page[1] that have been marked as done more than 28
days ago but: "(Closed bugs are cleaned out 28 days after the last related
message is received.)" I don't mind them being there but it's eating space
I guess (count yourself: 20kB bugs * 10kB avg/bug = 200 MB, possibly more)
Marcelo
[1]
http://www.debian.org/Bugs/db/ma/l,mmagallo,debian.org,Marcelo_E._Magallon.html
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: sleep contains crypto stuff?
[Moving to debian-policy per Joey's request, please continue
there]
On Sun, 12 Apr 1998, Martin Schulze wrote:
joey> > They are not. I pointed this out on debian-policy a while ago,
joey> > but nobody seemed to care. :-(
joey>
joey> Ok, now at least one care about it. Please bring it up on -policy
joey> again.
Ok, I'm enclosing the same message I posted to policy a while
ago. It's long. It's intent is to show the behaviour of the
linker.
Marcelo
Date: Mon, 26 Jan 1998 20:24:52 -0600 (CST)
Subject: Re: PW#5-7: Linking shared libraries with -lc
On Mon, 26 Jan 1998, Christian Schwarz wrote:
> It would be good if someone more experienced than I am could comment on
> Marcelo's arguments against linking shared libraries with `-l'. If his
> arguments are valid (I really can't tell) then we'll have to drop this
> release goal and the policy proposal.
Just to clean things a little bit. Here's what I have (please excuse me
for the long output transcription)
$ echo 'void hello() { printf("Hello,"); }' > libhello.c
$ gcc -c -fPIC libhello.c
$ gcc -shared -Wl,-soname,libhello.so.0 -o libhello.so.0 libhello.o -lc
$ ldd ./libhello.so.0
libc.so.6 => /lib/libc.so.6 (0x40005000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x)
$ echo 'void main() { hello(); printf(" world!\n"); }' > hello.c
$ gcc -o hello -Wl,-rpath,`pwd` hello.c ./libhello.so.0
$ ldd ./hello
libhello.so.0 => /home/mmagallo/develop/shlib-test/libhello.so.0
(0x4000c000)
libc.so.6 => /lib/libc.so.6 (0x40011000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x4000)
$ rm hello libhello.so.0
$ gcc -shared -Wl,-soname,libhello.so.0 -o libhello.so.0 libhello.o -lc -lm
$ ldd ./libhello.so.0
libc.so.6 => /lib/libc.so.6 (0x40005000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x)
libm.so.6 => /lib/libm.so.6 (0x400a8000)
$ gcc -o hello -Wl,-rpath,`pwd` hello.c ./libhello.so.0
$ ldd ./hello
libhello.so.0 => /home/mmagallo/develop/shlib-test/libhello.so.0
(0x4000c000)
libc.so.6 => /lib/libc.so.6 (0x40011000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x4000)
libm.so.6 => /lib/libm.so.6 (0x400b4000)
As you can see from the output above, ./hello ends up depeding on whatever
the library depends on. strace reveals the libm is loaded. I don't know
what for, but it's loaded. (Can somebody do this, and strace ./hello and
tell what's going on there?)
I think this is a bug in the GNU linker... or at least something to watch
out for. Please note that you can compile the programs without specifying
-lm. Hmmm... let's see about that:
$ echo 'void hello() { printf("Hello,"); }
void hello_math() { printf("%.2g", sin(1.57)); }' > \
libhello_math.c
Now libhello_math depends on libm
$ gcc -c -fPIC libhello_math.c
libhello_math.c: In function `hello_math':
libhello_math.c:1: warning: type mismatch in implicit declaration for built-in
function `sin'
$ gcc -shared -Wl,-soname,libhello_math.so.0 -o libhello_math.so.0
libhello_math.o -lc
note I'm not putting -lm here... this is current policy. This enables
dpkg-shlibdeps to make the package depend on libc6, which is desirable.
$ ldd ./libhello_math.so.0
libc.so.6 => /lib/libc.so.6 (0x40005000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x)
$ echo 'void main() { hello(); printf(" world!\n"); }' > hello_a.c
$ gcc -o hello_a -Wl,-rpath,`pwd` hello_a.c ./libhello_math.so.0
./libhello_math.so.0: undefined reference to `sin'
and hello_a is not linked. Note that hello_a.c doesn't call hello_math(),
just hello(). Let's try it again:
$ gcc -o hello_a -Wl,-rpath,`pwd` hello_a.c ./libhello_math.so.0 -lm
note -lm was added!
$ ldd ./hello_a
libhello_math.so.0 =>
/home/mmagallo/develop/shlib-test/libhello_math.so.0 (0x4000c000)
libm.so.6 => /lib/libm.so.6 (0x40011000)
libc.so.6 => /lib/libc.so.6 (0x4002a000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x4000)
$ echo 'void main() { hello_math(); printf(" world!\n"); }' > hello_b.c
$ gcc -o hello_b -Wl,-rpath,`pwd` hello_b.c ./libhello_math.so.0 -lm
$ ldd ./hello_b
libhello_math.so.0 =>
/home/mmagallo/develop/shlib-test/libhello_math.so.0 (0x4000c000)
libm.so.6 => /lib/libm.so.6 (0x40011000)
libc.so.6 => /lib/libc.so.6 (0x4002a000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x4000)
No difference. It doesn't matter if the program uses the functions calling
sin() or not. This is definitely a problem in the linker. The program has
to be linked with -lm.
Now I don't know what to think. What I posted before wa
Re: Anyone want to make a Debian XDM login screen?
On Mon, 13 Apr 1998, Frederic Peters wrote: > background where you type your login/password have to be in > only one color, no pixmap. Except that fact, I think a login > screen with only xdm (+xloadimage) can be really cool. I am ok > to make a great login screen. For graphics, I am not the man. > Why not call for graphics from the web site like when we were > looking for a logo ? That's all. you may want to take a look at login.app, that just uploaded. Marcelo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: xfont3d/xfpovray
On Mon, 13 Apr 1998, matthew.r.pavlovich.1 wrote:
> I wish to become a package maintainer, I stubbled across
> several really nice applications. They are xfont3d and
> xfpovray.
Can you provide an URL? What do these apps do?
Marcelo
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: elvis package
On Mon, 20 Apr 1998, Alexey Marinichev wrote:
> Anyway, I do not think we should have X support compiled in
> vim, rather it should be a different package or something like
> that. It's pretty bad debian policy forbids it.
Do like I do with wmaker: compile several binaries[1]. One with
X, one without. Use alternatives to manage the whole thing.
Marcelo
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: X and Window Mangers
On Mon, Apr 27, 1998 at 11:11:12PM -0600, Jason Gunthorpe wrote: > I was just setting up a new install and ran into the problem of wmaker > configuring itself before /etc/X11/window-managers existed, it's postinst > bombed. This was reported as a bug, and it is fixed on 0.14.1-4, is it not?!? (I ask because 0.14.1-4 is, I think, installed on master, anyway, I just uploaded 0.14.1-5) > I presume some X package creates this file since dpkg can't find it, this > also means that every window manager has a dependency on that package or > has a bug.. I had two options to fix this. First, the problem: xbase creates the file on postinst and wmaker's (and every other wm) postinst adds entries to the file. Fixes: 1) make wm predepend on xbase 2) make wm create the file. I *asked* on debian-mentors what to do, and nobody answered. I went for 2) The current postinst reads: if [ -e $wmfile ] ; then [ ... stuff to do if the file is there ] else cat >$wmfile <
Re: X and Window Mangers
On Tue, Apr 28, 1998 at 01:26:37AM -0500, Branden Robinson wrote: > 1) ship an empty /etc/X11/window-managers with xbase > 2) mark it as a conffile > 3) separate twm into its own package thanks!!! > 4) write /usr/sbin/register-window-manager > > register-window-manager [pathname] > [...] > > register-window-manager --add pathname > > register-window-manager --remove pathname Nice! Thanks Branden! > Of course, all window managers will have to depend on xbase for this to > work. Is there any reasonable scenario in which a user would have a > window manager installed but not xbase? (predepend, isn't it?) Given the binaries provided by xbase -- BTW, some of them are never used, I think -- I don't think you can run a WM without xbase installed. OTOH, if the wm is provided over NFS, there's a chance of having xbase (local) and wm (nfs mounted). That leads us into a pre-suggests (ugh!) situation. pre because xbase has to be configured before WM. suggests because it could run without xbase. I rather not see something like this (it's the same situation with menu, and it can be handled the same way), and I better get some coffee because I'm talking non-sense. Marcelo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: X and Window Mangers
On Tue, Apr 28, 1998 at 10:53:22PM -0400, Ben Pfaff wrote:
> Okay, it's a good thing you brought that up then. Does Branden's
> proposal include support for this? Perhaps I need to go back and read
> it better, but I don't remember anything about command-line options.
Branden proposes the existance of a script that is called on
post{inst,rm} which manages additions to
/etc/X11/window-managers. It's exactly the same as the current
situation, but in line with policy (besides making the whole thing
more consistent, and easier for window manager maintainers). That is,
Xsession calls the first valid program listed on window-managers.
The other is alternatives (/usr/bin/X11/sensible-window-manager), and
(here I'm guessing) /etc/X11/Xsession calls /usr/bin/X11/s-w-m because
that's the "default" window manager. So far, so good. I cann't name a wm
that gets its configuration from the command line.
> Are there some options that can't be passed to some window managers in
> configuration files?
WindowMaker has -nocpp, -nodock and -nofiend (there are options that
are not available on the configuration files). My point is having
/usr/X11R6/bin/sensible-window-manager as a symlink to wmaker would make
$ sensible-window-manager -nodock
valid, but if the default window manager is fvwm2, then it's
not. Alternatives, as I understood them, have to be command line
compatible because a situation like the one I just described is not
desirable.
Marcelo
pgp1uOI4q5Z7D.pgp
Description: PGP signature
Re: binary-CD exceeds 650 MB -- any solution?
On Tue, 21 Apr 1998, Avery Pennarun wrote: > If we include just the binaries from main and contrib, along > with the disks-i386 directory, we seem to get 659241 kbytes. I > can never quite remember whether a CD contains 640 or 650 > million bytes or megabytes, but this is TIGHT on space. > Shoving disks-i386 off to a different CD is probably sufficient > to clear it up, though. A few days ago I burned a CD with: * hamm/main/binary-i386 * hamm/main/binary-all * hamm/contrib/binary-i386 * hamm/contrib/binary-all * hamm/main/disks-i386 * hamm/indices * hamm/doc + linux/kernel/v2.1/linux*2.1.90*.bz2 + linux/kernel/v2.1/patch*2.1.9[1-6]*.bz2 I stripped everything not compressed that has compressed counterpart (Packages vs Packages.gz) and everything architechture specific leaving only i386 (for example, Packages*-alpha*). I'm sure I'm missing something here. The point is, all this fitted on 620 MB. I didn't include tools, which should go on the official CD. I'm not sure how much data fits on a disc, I mean, if one makes an image that's 649 MB, will that fit? I've read there are a few seconds (like 5s, roughly 800 kB) on the initial part of the disc that are not usable, but I don't know if that's already counted on the 650 MB figure. Marcelo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
ppp: how to tell the connection speed?
Hi,
I'm packaging wmppp.app 1.2 (a PPP monitoring tool that fits
on a 64x64 window) and it requieres an external program to determine
the connection speed. The sample program does this:
tac /var/log/messages | grep CONNECT | head -1
since /var/log/messages is not world readable, this program has to be
suid root, (yikes!) but on Debian, that's not a problem because it's
the same as
grep CONNECT /var/log/ppp.log | tail -1
and /var/log/ppp.log is world readable...
But the problem is I get:
[14 jacinta:~] grep -A 6 CONNECT /var/log/ppp.log | tail
May 1 16:54:37 jacinta chat[669]: expect (CONNECT)
May 1 16:54:37 jacinta chat[669]: ^M
May 1 16:55:07 jacinta chat[669]: ATDT207-5661^M^M
May 1 16:55:07 jacinta chat[669]: CONNECT
May 1 16:55:07 jacinta chat[669]: -- got it
May 1 16:55:07 jacinta chat[669]: send (^M)
May 1 16:55:07 jacinta chat[669]: expect (name:)
May 1 16:55:07 jacinta chat[669]: 14400/ARQ/V32/LAPM/V42BIS^M
May 1 16:55:07 jacinta chat[669]: ^M
May 1 16:55:07 jacinta chat[669]: ^M
(yes, I've got an 14.4 modem... I've never bothered to buy a new one)
As you can see chat breaks the CONNECT line. Is there a way to tell
the connection speed? Once on IRC I told Manoj to use $PPP_SPEED on
the ip-up/ip-down scripts, but he pointed out that that didn't report
the connection speed but the maximum speed on the line.
Is there a way out of this, or is this a case by case problem?
Thanks,
Marcelo
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: ppp: how to tell the connection speed?
On Sat, May 02, 1998 at 08:12:35AM -0500, [EMAIL PROTECTED] wrote: > Marcelo E. Magallon writes: > > As you can see chat breaks the CONNECT line. Is there a way to tell > > the connection speed? > > 'ATW2' will make the modem (or at least, my modem) emit something like > 'CONNECT 26400'. mine is ATX4 > Adding 'REPORT CONNECT' to the chatscript and giving chat the option > '-r ' will cause chat to write the CONNECT string to > . I tried it, but I cann't get it to work. I added -r /var/run/ppp.speed to the chat line in /etc/ppp/peers/provider and "REPORT CONNECT" as the first line on /etc/chatscripts/provider (I didn't find anything on the man page that says it has to go in some particular place). I made it output to /var/run/ppp.speed. Would that name be ok? I put it there instead of /var/log/ppp.speed because /var/run gets cleared on reboot, and I don't see any reason to keep the files between reboots. > I can have pppconfig add 'REPORT CONNECT' to the chatscript if there > is interest in this. That'd be nice. Sometimes I like to check the connection speed because the modem did funny noises (funnier than the usual), and a command like ppp_speed (or plog -s, but that's stretching it a bit) would be useful. > BTW has anyone else run across a modem that reports 'CARRIER' instead of > 'CONNECT'? My very first modem did that. But we are talking 1988 (whoa! it's been long) here and that was an El Cheapo 2400 Marcelo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: List of bugs that *must* be fixed before releasing Hamm
On Fri, May 01, 1998 at 12:38:24PM -0400, Brian White wrote: > > Brian, this is a useful list, but please sort it by Maintainer or by Package > > rather than by bug number: > > Several people have asked for this, but maintainers already get separate > reports about their packages and reports by package are available on > the web site, so I don't really understand the usefulness of presenting > it that way here. Is there something I'm missing? I'd like to take a shot at fixing some of these bugs (let me find the time first), and I'd be really helpful to be able to take a quick look at the number of bugs (and how closely related they are or not) a package has. Since I already get this on my inbox, it would be nice to have it sorted by packge. Marcelo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: library packaging doc...
On Thu, Jan 27, 2005 at 07:37:18PM +0100, Frank Küster wrote: > IIRC there were some people who objected to some of the contents of > the document. But even for those it is probably better to have a > Debian package - if it's important, the discussion will take place in > bug reports, instead of not taking place. I haven't read the document in question in a rather long time, so I can't actually object (on some sort of serious basis, I mean), but I would nevertheless request that the document be handed to the -english mailing list for proofreading *before* it's uploaded as a package and that a big "THIS IS A *GUIDE*" banner be stamped on it. The last thing I want is people complaining that libfoo doesn't follow some chapter and verse of said guide under the impression that it is somehow "correct", "standard" or "mandatory". Marcelo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: library packaging doc...
On Fri, Jan 28, 2005 at 12:20:25PM +0900, Junichi Uekawa wrote: > > I haven't read the document in question in a rather long time, so > > I can't actually object (on some sort of serious basis, I mean), > > but I would nevertheless request that the document be handed to > > the -english mailing list for proofreading *before* it's uploaded > > as a package and that a big "THIS IS A *GUIDE*" banner be stamped > > on it. The last thing I want is people complaining that libfoo > > doesn't follow some chapter and verse of said guide under the > > impression that it is somehow "correct", "standard" or > > "mandatory". > > I think this proofreading has happened some time ago; but will > definitely benefit from being proof-read again. Most definitely. Proofreading != spellchecking, you know? The (current!) document has a very, what should I call it? Bumpy style? Maybe even jolty. Your use of punctuation is... let's say unusual. What I'm saying is that it's hard to read. You provide little rationale at places where rationale is really needed and make some assertions at places where they are really not needed. Off the top of my head, the SONAME section could use some rewriting. The parts concerning to static libraries need some serious rewording. The part about version numbers really needs clear examples. In fact, the whole thing needs "do [this] and watch it break like [this]" examples. > This document has been around for more than 2 years now. I know. I didn't like it at the beginning either. It *does* contain some rather useful information, but again, it falls short at places where it shouldn't. > As for your objection of "correct", "standard" or "mandatory", I > would say that this document is a recommendation, and should be > followed when there is not a good argument against it. If there is a > good reason not to follow this document, in which case I would > recommend providing a patch against the libpkg-guide. What I'm saying is that -- in the same way that some people insist on Debian Policy to be followed blindly -- there are already some people insisting that this document be followed blindly. "Raising" the status of it to something more "official" would make things only worse. > After all, what this document tried to be is to document current > practice, backed with some bugreports resulting from mis-packaging; Yes, I still remember the discussion and I'm still burned out by it. I recall vividly how I had to waste much time to convince you that there was a problem with libpng in the first place and then even more time to get you to understand what the proper solution was. I really have no intention of rehashing that chapter. Marcelo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: mirror-2.9 released, and hopefully DFSG compliant
On Tue, Jun 02, 1998 at 04:27:48PM +0200, Santiago Vila wrote:
> Does this mean the modified-for-Debian "mirror" may not be distributed
> inside the .deb binary package?
Isn't that distributing modified bynaries? I mean, you are not distributing
the .orig.tar.gz, but something different (with added parts, and
incidentally, one of them is the original thing)
I got an announcement from Freshmeat that said GNU Mirror, and I thought
the licence was changed over to GPL... but isn't this one the same (close)
to the one Pine uses?
Marcelo
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Why do we still have this on the distribution?
Hi fellows, while grepping thru the Vancouver thread, I was trying to understand why Sparc isn't in the "likely first class citizens for etch" list. My impression was that Sparc is one of the "healthy" ports. Looking at http://buildd.debian.org/ I noticed that, say: http://buildd.debian.org/quinn-diff/output/unstable/by_priority-sparc.txt is three years old. Browsing even more I found: http://buildd.debian.org/stats/?arch=sparc&state=Needs-Build is I guess is better, but doesn't really help me understand some numbers others have posted (notably, that sparc is below the 98% line). Discussing this with someone who actually uses the Sparc port on a daily basis, we noticed that we still have php3 in the archive. Looking at depencencies I see: $ grep-available -n -s Package -F Depends php3 | sort -u acidlab acidlab-mysql acidlab-pgsql dacode dcl eskuel hawxy htcheck-php libphp-hawhaw libphp-phplot nagat php3-cgi-gd php3-cgi-imap php3-cgi-ldap php3-cgi-magick php3-cgi-mhash php3-cgi-mysql php3-cgi-pgsql php3-cgi-snmp php3-cgi-xml php3-gd php3-imap php3-ldap php3-magick php3-mhash php3-mysql php3-pgsql php3-snmp php3-xml phpgroupware-napster spip spip-eva twig I don't use PHP at all, but I know this much: PHP3 is code left to rot. Are people really maintaining code this old? Old per se is not the problem, but old, unmaintained, complex and shown to have security problems is. During the discussion another point came up regarding the download metrics: all architectures are equal, but some are more equal than others. You can't compare 16 i386s to a single sparc with 16 processors with such a metric. -- Marcelo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Why do we still have this on the distribution?
On Tue, Apr 05, 2005 at 04:43:06PM -0500, Gunnar Wolf wrote: > Out of those, they are all either available for php4 as well (php3-*) > or depend on either php3 or php4. Just to make the point more explicit: $ grep-available -n -s Package -F Depends php3 -a ! -F Depends php4 | sort -u php3-cgi-gd php3-cgi-imap php3-cgi-ldap php3-cgi-magick php3-cgi-mhash php3-cgi-mysql php3-cgi-pgsql php3-cgi-snmp php3-cgi-xml php3-gd php3-imap php3-ldap php3-magick php3-mhash php3-mysql php3-pgsql php3-snmp php3-xml $ grep-available -n -s Package -F Depends php3 -a -F Depends php4 | sort -u acidlab acidlab-mysql acidlab-pgsql dacode dcl eskuel hawxy htcheck-php libphp-hawhaw libphp-phplot nagat phpgroupware-napster spip spip-eva twig > Is there a real reason to keep carrying this cruft? I understand the > packages are not (or don't appear to be) buggy... However, their bits > are rotting. They are not widely used anymore, and they might have > all sorts of problems that do not get detected. I don't know if > patches for the php4 modules are backported (if the problem exists, > of course) for older php3 modules. Recently yet another PHP4 vulnerability was reported. Each time you have to wonder if it really doesn't apply to PHP3 or if noone bothered to look. -- Marcelo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: regarding gerris package
Hi Kamaraju, On Sat, Mar 04, 2006 at 01:33:09AM -0500, kamaraju kusumanchi wrote: > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=354032 > > asking for the latest version (0.8.0) of gerris which has been > available since Oct 17, 2005. I have not received any reply to this > bug report even after 10 days. I know that 10 days is not a very long > period of time, but I just want to make sure that this package is not > abandoned by you. Due to reasons that I prefer not to discuss on a public mailing list, I haven't worked on my packages for the last few months. The last time I was working on an updated gerris package I had several problems, mostly related to compiler changes in unstable. I just took a look at it, and it's still not compiling. If you have managed to compile a package for the newer versions, I will really appreciate a patch, if there's one. > If you want to abandon this package, please let us know by filing a > bug against wnpp package saying that you are orphaning this package. > This allows other interested persons (like me) to at least work on > this package. If you are willing to take over the package I'll be happy with that. Please drop me a note off-list letting me know that. Thanks, Marcelo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: hwcap supporting architectures?
On Tue, Jan 11, 2005 at 03:52:58PM +0900, GOTO Masanori wrote: > Note that MMX will be removed from the next glibc 2.3.4 upload. It > will provide only SSE2 (and CMOV, debian-specific for only VIA C3 > processor). Well, there's hand-crafted MMX code, so it's runtime checked. I guess that would take care of it. After following the advice in other replies, gcc is generating CMOVs, too. > If you want to keep adding mmx, we may need discussion about this > issue in future. I think MMX is ok. I don't think gcc is generating MMX on its own. > But nowadays many processors can use SSE2, so I guess changing cmov > to SSE2 can fix the problem. The SSE2 code generated by gcc causes clipping errors, so I turned that option off. > > My understanding is that this is also significant on sparc > > (-mcpu=v9) and that this belongs in /usr/lib/v9. Is this right? > > Sparc defines HWCAP_SPARC_V9 and HWCAP_SPARC_ULTRA3. So v9 is right. > See glibc sparc packages. Thanks! Where would ultra3 libs go? /usr/lib/sparc/ultra3? (sorry about the naive question, but I had a hardtime finding this sort of documentation) > > Mesa upstream uses -mcpu=ev5 -mieee on alpha. Is that ok? Where > > does this belong into? /usr/lib/ev5? > > IIRC, alpha does not define any hwcaps. Oh... I was looking at the atlas packages (I *think*), and it installed some libs in /usr/lib/ev5 (or something along those lines). Is that manually handled by atlas or something like that? > > It also uses -mcpu=603 on powerpc. From my understanding this is > > a lot hairier than other architectures since there's a whole load > > more subarchitectures which are potentially incompatible with each > > other. > > Powerpc does not define any hwcaps, too. Thanks for the help! Marcelo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: hwcap supporting architectures?
On Tue, Jan 11, 2005 at 11:27:28AM +0100, Falk Hueffner wrote: > Sensible options are ev56 and ev67; ev5 is not particularly useful, > since it has the same instruction set as the baseline ev4, only > different scheduling. -mieee is default anyway on Debian's gcc. If you have the time, hardware and desire to do so, you can compile the mesa package (there's a debian/README.build there) and if you find any significant advantage I'll gladly include any required change. Mesa is stuck in incoming atm. Marcelo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: hwcap supporting architectures?
On Sat, Jan 15, 2005 at 10:14:15PM +0900, GOTO Masanori wrote: > > occurs when you have for example an ev56 library in lib/ev56, and a > > ev67 CPU. Then the loader looks in lib/ev67 and then falls back to > > lib. Since glibc is very carefully undocumented in this area [1], I > > didn't want to try to change this, but rather assumed one could add > > a symlink. > > Yes, and if ev67 is instruction upper compatible with ev56 (I guess > so), I think it's acceptable to add a symlink "ln -sf > lib/ev67/libfoo.so lib/ev56/libfoo.so". Ugh... that pushes the burden of maitaining support for new architectures to the package. Please bear with me, but I'm trying to understand the issue: is the cost of calling access(2) or stat(2) really so high? I see for example that on start up the file /etc/ld.so.nohwcap is accessed multiple times (and it's not present, isn't that a race? what happens if the file suddenly appears in the middle of program start up? what's that file anyway, I can't find it mentioned in the documentation). Marcelo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: hwcap supporting architectures?
On Mon, Jan 17, 2005 at 05:52:04PM +0900, GOTO Masanori wrote:
> > > > Yes, and if ev67 is instruction upper compatible with ev56 (I
> > > > guess so), I think it's acceptable to add a symlink "ln -sf
> > > > lib/ev67/libfoo.so lib/ev56/libfoo.so".
> > >
> > > Ugh... that pushes the burden of maitaining support for new
> > > architectures to the package.
>
> Yeah - I think it's trade off - whether we support library
> optimization package or we don't get a bit performance improvement.
So, you are trading maintainance cost for a rather subjective speed
improvent? Or should I say, preventing some performance degradation?
Keep reading.
> > > Please bear with me, but I'm trying to understand the issue: is
> > > the cost of calling access(2) or stat(2) really so high?
> >
> > I'd consider it quite acceptable in this case. However, as I tried
> > to express, it's not possible with glibc's current "design", and I
> > didn't feel like changing that.
>
> Note that we should keep in mind: imagine most binaries on all debian
> system over the world start to consume access(2)/stat(2) system call
> cost in each binary execution time - "Many a little makes a mickle".
Ok, I stopped buying this kind of argument long ago. There's a
SIGGRAPH paper (2001 IIRC) which justifies certain kind of rather
complex optimization because a (graphics) context switch is "too
expensive", without actually defining the situation that triggers the
context switch in a clear fashion. In my own testing context switches
of the kind described in that paper are at least a factor of 100
_faster_ than what the authors claim.
Attached is a program that measures the time a single stat(2) call
takes. I get circa 5 microseconds per stat(2) call on my computer (AMD
Athlon 1600+, can't recall what kind of memory it has right now). Note
that the code that doesn't directly have to do with the stat(2) has a
rather low overhead (circa 1 ns on my system).
What that means is that you need to make about 2000 stat(2) calls to
get _anywhere_ near what's measurable by a human and about 2 to
start getting said human annoyed.
If a biggish GNOME program (Epiphany Browser) links to 60 libraries,
you need to perform a lookup in ~ 30 paths for the start up delay to be
measurable and ~ 300 for it to be annoying. ls(1) links to 6
libraries. That's one order of magnitude less, IOW, you need a path
with ~ 3000 components to start being annoying.
So, what exactly are you talking about?
> > > I see for example that on start up the file /etc/ld.so.nohwcap is
> > > accessed multiple times (and it's not present, isn't that a race?
> > > what happens if the file suddenly appears in the middle of
> > > program start up? what's that file anyway, I can't find it
> > > mentioned in the documentation).
> >
> > It's supposed to disable the use of hwcaps. Stating it multiple
> > times seems like a bug.
The contents does not matter?
> Debian glibc has been applied a special patch to check
> /etc/ld.so.nohwcap before loading libraries each time. You can see
> it in debian-glibc package ldso-disable-hwcap.dpatch written by Ben
> and Daniel. It enables us to upgrade smoothly even if we use
> optimized libraries - this effort is one of debian's nice features.
> But the drawback is it needs to pay access(2) lookup cost as you
> pointed out.
>
> Checking /etc/ld.so.nohwcap each time (some binaries call multiple
> times) is the current patch design
Why? I just can't see a valid reason for "wanting" the file to
suddenly pop up while the program is running.
> I think this is safer than checking /etc/ld.so.nohwcap once in
> program startup time.
Safer in what way?
Again, I just don't buy that "system calls are too expensive" argument.
Anyone writing shell scripts cares about a whole lot of things *but*
performance. And I'm not talking about increasing running time by a
factor of anything, I'm talking about adding a bunch of microseconds,
which get lost in the middle of filesystem stalls, page faults and
other rather common events.
Marcelo
#include
#include
#include
#include
#include
#include
#include
int main(int argc, char * argv[])
{
const int N = 6;
char name[N+1];
for(int i=0; i < N; ++i)
name[i] = '0';
name[N] = 0;
struct timeval t0, t1;
gettimeofday(&t0, NULL);
for(int i=0; i < N;)
{
struct stat buf;
stat(name, &buf);
for(i=0; i != N && ++name[i] == '9'+1; ++i)
name[i]='0';
}
gettimeofday(&t1, NULL);
float dt = (t1.tv_sec - t0.tv_sec) + (t1.tv_usec - t0.tv_usec)*1E-6;
printf("%g\n", dt/powf(10, N));
return 0;
}
Re: hwcap supporting architectures?
On Wed, Jan 19, 2005 at 09:43:18AM +0100, Bernd Eckenfels wrote: > I agree with you, but dont forget that this micro benchmark does not > really measure the overall effect on the system (i.e. to other > programs, to the number of meta data updates, cach useage) and it > does not take into account slow or unreachable path components (nfs). Agreed. The intention of the benchmark is not to claim that the operation that ld.so is performing is fast; it's just to provide some quantifiable argument for or against the "system calls are way too expensinve" meme. *My* position is that whilst they are expensive (certainly much more expensive than a function call), they are not _that_ expensive. Before asking here I went thru several mailing list archives. What I found was a general argument along the lines of "don't add _that_ hwcap because that will increase the size of the list of paths that you have to stat(2) in order to find the library and that's slow". In particular upstream doesn't seem to like the idea much. I just can't find the reason why they think the stat(2) call is _so_ expensive that it will hurt system performance. There was some mention of a glib issue with plugins. I couldn't find further data points on that... > So it might be actually noticeable on normal systems (I doubt it). > Just dont stop anyone volunteering from fixing it. I for one are > happy if the strace of a process keeps readable in finite time, so do > system administrators with auditing turned on. I can understand that. I'm just not sure what's to fix in the first place. Marcelo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: hwcap supporting architectures?
On Wed, Jan 19, 2005 at 01:20:56PM +0900, GOTO Masanori wrote: > > > > > Ugh... that pushes the burden of maitaining support for new > > > > > architectures to the package. > > > > > > Yeah - I think it's trade off - whether we support library > > > optimization package or we don't get a bit performance > > > improvement. > > > > So, you are trading maintainance cost for a rather subjective > > speed improvent? Or should I say, preventing some performance > > degradation? > > The reason why I don't try to clear hwcap issue in documentation is: > I don't want to battle to someone about this kind of issue. Buying > new hardware improves performance. I don't reply any more. Whatever. If you just don't want to discuss the "nice" feature, I won't force you into the discussion. "Buy new hardware" is a argument _against_ your general statement, so I have no idea where you want to go with that. I _do_ need to point out that /etc/ld.so.nohwcap is not documented anywhere where the user can find about it: $ zgrep nohwcap /usr/share/doc/libc6/* /usr/share/doc/libc6/changelog.Debian.gz: /etc/ld.so.nohwcap is 0. But I guess that just being consistent with upstream's tradition. Trying to find documentation about LD_DEBUG (for example) is frustrating at best. ld.so(8) doesn't even mention the variable! Either you *bump* into LD_DEBUG=help by chance or go RTFS, which is, quite appropriately, also badly documented. But it's fine, don't bother to reply, you certainly have better things to do than justify backward designs and weird decisions which are probably not yours to begin with. Marcelo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: BTS "feature" comments
>> Darren Benham <[EMAIL PROTECTED]> writes: > What do you think? well, for one, the submitter doesn't have to be a developer, and it's perfectly ok for the submitter to manipulate "his" bugs. I've always thought the rule "only the maintainer and the submitter are allowed to close bugs" to be a good one. In fact, as a submitter I've closed or reassigned bugs several times... as a maintainer, I've found some bugs have been reassigned or closed by the submitter, and I was pleased about it... > On 21/09, Darren Benham wrote: > > | And do what... there are going to be keys that aren't in the debian > keyring.. > > Non-developpers should not be allowed to *manipulate* bugs IMO. why would I start marking bugs in, say xfree, as fixed if I'm not the maintainer. I asked Branden about this once, and *he* asked me to submit reports to the corresponding bugs and, iirc, mark them fixed. But in that situation I had permission from the maintainer, which is a good thing. Marcelo
Re: debhelper compilation on slink
>> Colin Marquardt <[EMAIL PROTECTED]> writes: > I´m trying to compile a new debhelper on a slink system (which in > turn I want to use to build lm_sensors -- it needs dh_link which > isn´t in my slink´s debhelper 1.1.24). You can just install debhelper 2.0.50 from potato on a slink system, all the dependencies are met. Marcelo
Help debugging X program (moonlight)
Hi,
[ please keep me on the Cc:, I'm not on -devel atm ]
this is driving me nuts. moonlight segfaults on start up if libGL.so
is utah-glx's instead of regular mesa's. I have recompiled the
bloody thing against utah-glx's libGL.so (it was using some Mesa
extension that utah-glx doesn't provide) and now I'm dealing with
what seems to be a documentation problem... compiled in `development
mode' (that means don't strip the thing a behave a little different),
I'm getting:
[604 ysabell:~/devel/debian/moonlight/moonlight-0.5.3/src] gdb
main/.libs/moonlight-0.5.3 core
[...]
(gdb) bt
#0 0x401c5627 in ErrorHandler (display=0x804efa8, event=0xb35c)
at XGraphicsSystem.C:138
#1 0x4043ba5d in _XError () from /usr/X11R6/lib/libX11.so.6
#2 0x4043a14b in _XReply () from /usr/X11R6/lib/libX11.so.6
#3 0x404293c3 in XInternAtom () from /usr/X11R6/lib/libX11.so.6
#4 0x401cf84e in set_mwm_border (dpy=0x804efa8, w=41943087)
at set_mwm_border.C:73
[...]
(gdb) list
133
134 #ifndef NDEBUG
135 // crash 'n' burn for debugging purposes
136 char *str;
137 str = NULL;
138 *str = '0';
139 exit(-1);
140 #endif
141
142 return 0;
(gdb) list set_mwm_border.C:73
68 /* setup the property */
69 motif_hints.flags = MWM_HINTS_DECORATIONS;
70 motif_hints.decorations = flags;
71
72 /* get the atom for the property */
73 prop = XInternAtom( dpy, "_MOTIF_WM_HINTS", True );
74 if (!prop) {
75/* something went wrong! */
76return;
77 }
(gdb) print *event
$1 = {type = 0, display = 0x804efa8, resourceid = 71, serial = 92,
error_code = 8 '\b', request_code = 1 '\001', minor_code = 0
'\000'}
Error code 8 is (X11/X.h):
#define BadMatch 8/* parameter mismatch */
but XInternAtom(3x) says:
XInternAtom can generate BadAlloc and BadValue errors.
wtf!
Even more confusing, XRequest.1 is X_CreateWindow. X_InternAtom is
XRequest.16... aggghhh! There's a XCreateWindow a few lines
before the call to XInternAtom, but none of the documented reasons
for a BadMatch generated by XCreateWindow are met.
Help? Anyone?
Marcelo
Re: Potato now stable
>> Joey Hess <[EMAIL PROTECTED]> writes: > Jason Gunthorpe wrote: > > Tasks are bettered handled through some kind of non-package means. I've > > long said we need to determine some kind of meta-package scheme (a > > 'package' whose only purpose is to logically group other packages). > > How is introducing some basterdized form of package (perhaps it's just > an entry in the Packages file or something), going to allow us to > address problems like aj was talking about, where one of the things it > depends on is removed from debian, and it needs to be updated? in the one bit you trimmed out, Jason said: > Logically, the way to represent this is to have package declare > their membership in a grouping. This could be done via the override > file so as to maintain a centralized authority like we have no with > the task packages. Groups and user preferences about them could be > stored seperate to the status file. This wouldn't be that difficult. Just add a 'Task:' field to the packages. Have the default be non-existant (empty). In order to add information to the overrides file (and not put the load on the ftp people's shoulders) have a 'maintained overrides', that is, a bit of the overrides file maintianed just like a normal package (e.g., task-games.overrides). In this way you satisfy aj's concerns (changing this would be as short as editing a text file, signing and uploading) and provide the functionality of task-packages, provided UI tools support this field. One problem here is that sooner or later someone will start thinking of such sick things as 'local overrides'. Marcelo
Re: RFP: Quadra -- a multiplayer networked smooth tetris game
Hi, >> "Edward C. Lang" <[EMAIL PROTECTED]> writes: > MEM> It be nice if someone packages Quadra for Debian. It's a > MEM> tetris clone with single and multiuser modes, playable over > MEM> tcp/ip, featuring smooth graphics, worldwide high score lists, > MEM> servers and what not. > > Is it significantly different to Tetrinet? I know that gtetrinet is > packaged; what's more, it is licenced under the GPL. tetrinet? /me looks... wow. Some people certainly dig this game, don't they? Again, I'm not a tetris fan, but as far as I can see, the differences are pretty much a look and feel thing. Quadra is fullscreen and as far as I looked at it it's not themable as gtetrinet. I don't know if it supports tetrinet, but I doubt it. I don't know if gtetrinet /really/ requires GNOME (it says so on its readme and the package does require the GNOME libs), Quadra doesn't. As said, it's pretty much a self contained package. It sounds like you like tetris, perhaps you could take a look at Quadra and point out if it's really worth the effort. My naive non-tetris-fan experience suggests people who like tetris would like this game. But my naive non-tetris-fan experience is turned into nothingness after seeing what tetrinet is. Cheers, Marcelo
Re: Implementing "testing" (was: Re: Potato now stable)
>> Anthony Towns writes:
> Another reason to run unstable is to live on the actual bleeding edge:
> testing will always be around two weeks out of date. That can be a fair
> while, if you're impatient.
At best. Please remember there are some maintainers that will have to
be forced to take a two week and one day vacation in order for their
packages in unstable to get two weeks old.
/me ducks!
Marcelo
Re: WNPP now on the BTS
Hi,
>> Anthony Towns writes:
*sip*
After reading and rereading the Developer's Reference and the QA
docs, I did away with that oh-not-so-good WTO/ITO classifications and
added a RFA, as per your suggestion. Attached is the intended
documentation for the WNPP system.
Marcelo Work-Needing and Prospective Packages, WNPP for short, is a pseudo
package on the Debian Bug Tracking System (BTS) and its intention is to
track closely the real status of such things as prospective packages in
Debian and packages in need of new maintainers. Since it uses the BTS,
every developer is already familiar with the technical details, such as
submission of new information, modification of information or closing
of pending requests. On the other hand, in order to achieve the
highest level of automatization, some procedures have to be observed.
In order to submit new information, a bug has to be filed against the
wnpp pseudo package for each (prospective) package that is affected.
The format of the submission should be like this:
To: [EMAIL PROTECTED]
Subject: {TAG}: {package name} -- {short package description}
Package: wnpp
Severity: {see below}
{Some information about the package. If this is an ITP or RFP an
URL where the package can be downloaded from is required, as well
as information concerning its license.}
The tags to be used and their corresponding severities are:
Onormal The package has been Orphaned. It needs a new
maintainer as soon as possible. If the package
as a Priority of standard, required or essential,
the severity should be set to important. If the
package remains in this orphaned state after one
month, the severity will be raised to important and
the ftp maintainers will be asked to move it to
project/orphaned.
RFA normal This is a 'Request for Adoption'. Due to lack of
time, resources, interest or something similar, the
current maintainer is asking for someone else to
maintain this package. Meanwhile the package is
being maintained, but perhaps not in the best
possible way. In short: the package needs a new
maintainer.
ITP wishlist Someone 'Intents To Package' this. Please submit
a package description along with copyright and URL
in such a report.
RFP wishlist This is a 'Request For Package'. Someone has found
an interesting piece of software and would like
someone else to package it for Debian and upload
it to the archives. Please submit a package
description along with copyright and URL in such
a report.
Wwishlist The package has been withdrawn and can be found
in project/orphaned. Such reports should not be
submited directly, but instead should be a product
of retitling and downgrading 'O' reports.
The procedures for closing this bugs are as follow:
Oadopt the package, upload to the main archive and close this
bug once the package has been installed. If you are going
to do this, retitle the bug with 'ITA:' + the old title.
This is necessary in order for other people to know the
package is being adopted and to prevent its automatic removal
from the archive.
RFA adopt the package, upload to the main archive and close this
bug once the package has been installed. If you are going
to do this, retitle the bug with 'ITA:' + the old title.
This is necessary in order for other people to know the
package is being adopted.
If you as the package maintainer decide to Orphan the package,
please retitle as necessary. If you withdraw your request,
please close the bug.
ITP package the software, upload to the main archive and close
this bug once the package has been installed.
If you change your mind, and no longer want to package this,
either close the bug or retitle and reclasify it as RFP, as
you see fit.
RFP package the software, upload to the main archive and close
this bug once the package has been installed. If you are
going to do this, retitle the bug as 'ITP:' + the old title.
Wadopt the package, upload to the main archive and close this
bug once the package has been installed. If you are going
to do this, retitle the bug with 'IT
Re: Pre-ITA: ntop
>> "Oliver M . Bolzer" <[EMAIL PROTECTED]> writes:
> # BTW, is there any docu on how to properly operete the new WNPP ?
See http://www.debian.org/devel/wnpp/
Marcelo
Re: Help on Debian Project - Need Me?
>> Franklin Belew <[EMAIL PROTECTED]> writes: > If debian isn't even good enough to make our own web pages, how is that > going to look in the public eye? > > 'Yeah, our distribution kicks ass but our web pages require Windows2k > and X proprietary software programs to produce' > > Get a grip Brace yourself for impact: our logo was not created using free software. Even more, software packaged by us wasn't even involved, AFAICR. Now that the logo exists, someone would probably be able to reproduce it using the Gimp or Octave or Perl or something like that. The person who actually created it didn't use any of that because he was more confortable using other tools in another environment. The question is not whether the final product, specifically graphics or templates, can be created using Debian, but whether the person *actually creating* it feels confortable enough with the tools provided. No tool is inherently wrong for a given task, and this specially true when you are talking about graphics production. I know a guy who used to sketch portraits on his computer. Using a CAD program. Cheers, Marcelo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Help on Debian Project - Need Me?
>> Andreas Fuchs <[EMAIL PROTECTED]> writes:
> None of them look DFSG-Free to me. Nonetheless, SMIL _is_ a nice tool
> to produce something multimedia-ish. Hopefully, somebody writes a
> DFSG-Free player in the near future -- but it won't be me, I don't
> need it (-:
JFTR: http://www.swift-tools.com/Flash/
It's GPLed.
Marcelo
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RFC: moving packages to project/orphaned
Hi, In my never ending quest to get flamed over the WNPP, the next phase is moving orphaned packages to project/orphaned. I intend to generate weekly reports straight out of the WNPP information contained on the BTS and mail them to debian-devel-announce. The attached file is the information that would be sent. Suggestions regarding improvements are welcomed (specially wrt the wording of the text, lately my English stinks more than usual) If you take a look at that file you'll note: | The following packages are orphaned but still in the archive. | Unless they are adopted before they are 28 days orphaned, it will | be requested that they are moved into project/orphaned: and a large list of packages after that. This is what the QA docs[1] say happens. I actually need to filter out packages according to priority, that means a request to remove silo *won't* be sent, so please don't flame me on that one. OTOH, a request to remove csh will be sent eventually unless ejb is really maintaining csh. That is to say, the WNPP information still needs cleaning. Before sending this weekly reports I intend to mail [EMAIL PROTECTED] asking for confirmation whether the package is really up for adoption/orphaned. After that, what will happen is this: * Every friday a mail will be sent to d-d-a with a list of packages in need of a new maintainer and orphaned packages. * Every day a script will run thru the list of packages marked as "Orphaned". For every package (< important) which has been orphaned longer than 28 days, a bug will be submitted against ftp.debian.org requesting the package to be moved to project/orphaned. Once the package is there, the corresponding wnpp bug will be downgraded and retitled as "Withdrawn". Regarding the severity of the ftp.debian.org bug: important. Rationale: in the general case, packages that managed to get to this state are non-interesting (otherwise they would have been adopted already). That means it's a non maintained package which noone cares about, which in turn means bugreports won't get answered to. IMO, they *should* be removed before release. Counter-arguments for the general case are welcomed. Thanks, Marcelo [1] http://qa.debian.org/documentation/qa.html/ch-rules.html The follwing packages need a new maintainer: abuse (69632), 12 days old abuse-lib (69633), 12 days old admesh (68300), 33 days old aribas (68301), 33 days old atari800 (69634), 12 days old auto-pgp (68134), 33 days old axe (68172), 33 days old biss-awt (68218), 33 days old blast (69635), 12 days old bugsx (68303), 33 days old circlepack (68304), 33 days old clif (68191), 33 days old ctklight (68193), 33 days old docbook-doc (68219), 33 days old drawmap (68307), 33 days old dstool (68308), 33 days old dstool-doc (68309), 33 days old dstooltk (68311), 33 days old dstooltk-doc (68312), 33 days old emacs-czech (68275), 33 days old emacs19 (68281), 33 days old empire-ptkei (68130), 33 days old ffingerd (69007), 22 days old floatbg (69636), 12 days old fvwm fvwm-common (68154), 33 days old fvwm1 (68146), 33 days old fvwmconf (68313), 33 days old g2 (68314), 33 days old gclinfo (68182), 33 days old geomview (68315), 33 days old gmp1 (68136), 33 days old grafix (68317), 33 days old gtkglarea (68137), 33 days old gtkglareamm (68131), 33 days old guavac (68246), 33 days old hp48cc (68297), 33 days old hugs (68186), 33 days old hugs-doc (68187), 33 days old hypermail (68150), 33 days old jde (68713), 26 days old jgraph (68113), 33 days old libdelimmatch-perl (68220), 33 days old libnewt-perl (68141), 33 days old librc21 (68260), 33 days old login.app (68239), 33 days old luxman (69637), 12 days old m2c (68319), 33 days old mctools-lite (69638), 12 days old megahal (69639), 12 days old meschach (68320), 33 days old meschach-dev (68321), 33 days old mhash (68234), 33 days old mhonarc (68829), 24 days old mirrormagic (69640), 12 days old mixal (68183), 33 days old mpsql (68054), 33 days old nase-a60 (68184), 33 days old nwrite (69641), 12 days old omniorb (68710), 26 days old openc++ (68323), 33 days old pente (69642), 12 days old peruser (68124), 33 days old php3-dbase (68235), 33 days old plplot (68196), 33 days old rosegarden (68189), 33 days old saml (68199), 33 days old scheme-to-c (68112), 33 days old sciplot (68200), 33 days old sipp (68201), 33 days old sipp-dev (68202), 33 days old slatec (68203), 33 days old slatec-dev (68204), 33 days old space-orbit (69644), 12 days old super (68153), 33 days old tela (68205), 33 days old thrust (69645), 12 days old tkcdlayout (68099), 33 days old tochnog (68206), 33 days old tochnog-doc (68207), 33 days old toshutils (69646), 12 days old troffcvt (68263), 33 day
Re: RFC: moving packages to project/orphaned
>> William Lee Irwin III <[EMAIL PROTECTED]> writes:
> > hugs (68186), 33 days old
> > hugs-doc (68187), 33 days old
>
> I was under the impression that I was taking care of these two
Package: hugs
Maintainer: Antti-Juhani Kaijanaho <[EMAIL PROTECTED]>
Package: hugs-doc
Maintainer: Antti-Juhani Kaijanaho <[EMAIL PROTECTED]>
please do retitle bugs 68186 and 68187 if you are taking over these
packages. See http://www.debian.org/devel/wnpp/
Thanks,
Marcelo
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFC: moving packages to project/orphaned
>> Michael Meskes <[EMAIL PROTECTED]> writes:
> On Sun, Sep 03, 2000 at 06:55:16PM +0200, Marcelo E. Magallon wrote:
> > mpsql (68054), 33 days old
>
> How on earth did this make it onto your list. I cannot remeber orphaning it
> at all.
please do close bug #68054 if the package is no longer up for
adoption. The number after the package name is the bug number on
the BTS. If anyone else who notices that any information on this
list is wrong, please go ahead a fix it. See
http://www.debian.org/devel/wnpp/
As to how the information got there, the old WNPP database had this
package tagged as up for adoption, with you as the maintainer. Yes,
the wording on this report needs improvement.
Thanks,
Marcelo
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFC: moving packages to project/orphaned
Hi, >> Michael Meskes <[EMAIL PROTECTED]> writes: > On Mon, Sep 04, 2000 at 08:55:29AM +0200, Marcelo E. Magallon wrote: > > please do close bug #68054 if the package is no longer up for ^^ > > adoption. The number after the package name is the bug number on > It is up for adoption but this is not the same as orphaned by any means. | The follwing packages need a new maintainer: | ... | mpsql (68054), 33 days old | ... | ... | The following packages are orphaned but still in the archive. Unless | they are adopted before they are 28 days orphaned, it will be requested | that they are moved into project/orphaned: Instead of the first line, will: | The following packages are up for adoption, please contact the current | maintainer for more information: do? (with "the current maintainer"'s email listed next to them) Thanks, Marcelo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: X and runlevels
>> Branden Robinson <[EMAIL PROTECTED]> writes: > and sent patches to XFree86 a long time ago, but the patch was > ignored, and Dirk Hohndel basically told me I was an idiot for > doing so, because it might unexpectedly terminate the server in the > quite common case of four X session logins in a row that averaged > less than 6 seconds each... Huh all right. I don't understand what you/he meant by that, but the code that was patched (the xdm shipped with 3.3.2) was broken. In fact, the current code in 4.0.1 has been heavily patched to *enable* this functionality. No idea when that happend, sometime between 6.3 and 6.4 it would seem, and AFAICS, it was patched up-upstream, not by xfree86. The patch worked based on the *number* of consecutive failures. The current code works based on the *time* between failures, and it's rather agressive at that IMO. Amazed, Marcelo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: QT-GPL
>> Joseph Carter <[EMAIL PROTECTED]> writes: > Anyone checked the temperature in Hell lately? Not really, but I hope Therese enjoyed it... Marcelo, making obscure references to an endothermic hell -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#71107: [wmono@debian.org: Re: RFC: removal of libqt1g from woody]
>> Michael Beattie <[EMAIL PROTECTED]> writes: > The maintainer may be unaware of our conversation, (god knows why) > and may be working on an upload as we speak. IMO, its the same > philosophy as doing a NMU. Oh, yeah. http://bugs.debian.org/68274 It's orphaned. And has been for about 7 months. The "maintainer" should be debian-qa, but it has not been reset to that. Marcelo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: ITP: charities.cron
>> [EMAIL PROTECTED] writes: > http://freshmeat.net/projects/charities.cron/ > > I'll look at it and make a package, unless someone really objects... Fix the tmp security hole while you are at it, will you? Thanks, -- Marcelo
Re: List of packages that could be dropped
>> Wichert Akkerman <[EMAIL PROTECTED]> writes: > > Is any package using functions of dpkg-perl or dpkg-python? If yes, I > > think someone should take care of this packages and the bugs that are in > > them. If not, could we move this packages from our distribution to > > experimental until they are fixed and a new maintainer for them has been > > found? > > tetex depends on dpkg-perl. The WNPP report included backwards dependencies, until Packages-all-non-msdos-names (or whatever the name was) went poof. I haven't had the time to hook things to the new database. -- Marcelo
Re: Bug#81180: ITP: aterm -- an x terminal emulator
>> Chris Gray <[EMAIL PROTECTED]> writes: > Description:<http://aterm.sourceforge.net> [4 ysabell:~] grep-available -s Package,Maintainer -P aterm Package: aterm-ml Maintainer: Jordi Mallach <[EMAIL PROTECTED]> Package: aterm Maintainer: Jordi Mallach <[EMAIL PROTECTED]> Please close bug#81180 as appropiate. -- Marcelo
Re: Avifile package - help needed
Hi Zdenek, >> Zdenek Kabelac <[EMAIL PROTECTED]> writes: > After a while there is finaly version which looks stable enough for me, > so there are new packages of this program available here I went back to the archived discussion that took place in October, and I'm surprised noone pointed this out. As far as I can tell, DivX, what that codecs package contains, is illegal. It started off the Microsoft DLLs for MPEG4, got reverse- engineered and disasembled, patched and compiled again into the DivX codecs. The license on the original DLLs explicitly forbids reverse- engineering them. Since the machine in question is in the US (better said: in the same jurisdiction where this reverse-engineering act is illegal) and since there's not even a hint about *who* the author of that CODEC is, even less about it's copyright status, could you PLEASE remove the files from *.d.o machines? Thanks, Marcelo PS: go to http://xmps.sourceforge.net/, try to find the link to these win32 codecs there.
Re: Avifile package - help needed
Hi Zdenek, [ I hope you don't mind me mailing the reply back to d-d, please keep your replies there ] >> Zdenek Kabelac <[EMAIL PROTECTED]> writes: > But in this case - maybe downloading script would be legal for Debian ? > (just like for realplayer ? - or do you think Debian user should never > see any DivX-ed movie ?) Well, AFAICS the installer would cp *.dll /usr/lib/win32/ or something along those lines, wouldn't it? Up to that point, I guess it's ok, but I *would* frown upon an installer that downloads the files from some location, not because of what I think of DivX, but because such an installer is specifically designed to aid in the distribution of material that is potentially illegal and nothing else. -- Marcelo
Re: Avifile package - help needed
>> William Lee Irwin III <[EMAIL PROTECTED]> writes: > Say, could you cite some proof of this? I admit this being hearsay. Before sending my previous message I did try to find some credible source for this information. The Project Mayo doesn't give much info in that direction, and the articles it links barely mention the issue. The sites that did contain the information are gone or have changed since then. The only site where you can find something along these lines is, *gasp*, slashdot. Mac Station (http://www.mac.st/) claims to provide the source to a DivX CODEC, but I couldn't decompress the file to verify this. I wouldn't repeat this information if the DivX authors had cared to say "no, that's not true". > I've been in some email discussions with the author of mplayer about > what sort of licensing needs to go on with this and this has a > serious impact on the functionality of the player(s) involved. If > there's an post in debian-legal, or even better some public > information source with a statement to this effect, I want to see it > before I tell him we can't redistribute his package or whatever this > means. As long as mplayer doesn't *require* DivX to work, it should be safe. For example, xine can *use* the Windows DLLs, but it doesn't require them. I guess mplayer is in similar position. -- Marcelo
Re: Bugs about new upstream versions
>> Lars Wirzenius <[EMAIL PROTECTED]> writes: > Most packages are maintained by developers who are getting their job done > properly. They will notice the new upstream version and will update the > bug as soon as they can. Filing bugs will only take up their time. Let me put it this way: if I get a bug report that says "foobar 0.2 came out this morning" its only effect will be to delay the release of a debian package by at least a couple of days. OTOH, if it says "foobar 0.2 is been out for a couple of months now" you'll probably get a friendly message thanking you for the reminder and possibly a package within 24 hours. In other words: stop pestering Myth about a new mozilla package unless you want to have a package next year. -- Marcelo
Managing package sources with subversion?
Hi folks, I was looking for some pointers about managing package sources with subversion. I've got a grasp of the basics and I have looked at a couple of examples (most notably Branden's SVN repository for the XFree86 packages). My main concern right now is migrating an _existing_ CVS repository which is being managed with cvs-buildpackage to SVN, but I'd appreciate other tips. TIA, Marcelo
texmf.cnf again
Hi, I don't want to submit a bug since the last time this was discussed it degenerated into a flamewar and from the text I quote below it seems it's an emotionally overloaded issue for you. Installing tetex-bin brings up this: [!] Configuring Tetex-bin Now we can generate texmf.cnf, the central configuration file for TeX system, automatically with update-texmf script. This is necessary for other TeX related packages to update the contents of texmf.cnf But this overwrites the existing texmf.cnf so if you don't want it, don't accept this. Then you should modify /etc/texmf/texmf.cnf manually. But REMARK that you could fail to install some TeX components afterwards. For many users, it is recommended to accept this, despite the default was set contrary, because this is necessary to install many other TeX related packages and, if you want, you can custmize texmf.cnf freely only with modifying files in /etc/texmf/texmf.d/ and adding necessary file(s) there. Use automatic generation of texmf.cnf with update-texmf? <_No_> So the gist of that text is: "debian packages can manage the configuration file by themselves, it's a good idea if they do and there's a chance something will break unless you really really know what you are doing". Then why does it default to "no"? Along the same line: why is this high priority question if, by the look of it, only a handful of people would care? This is release-note worthy or handbook worthy, but it's not really the kind of thing Average Joe wants to see when installing Debian afresh[0], is it? Small request: please run that text thru our English l10n team ([EMAIL PROTECTED]) Marcelo [0] Which I did just last week... boy, is it confusing!
Re: Bug#193497: marked as done (svtools: svsetup uses bashism "echo -e")
On Sun, Jun 01, 2003 at 02:59:40PM +0200, Rene Engelhard wrote: > >* New upstream version (Closes: #193497) > > Meep. No. > > Write proper changelogs and(or close bugs the right way[tm]. That > form is only acceptable for "New upstream version, please package it" > like bugs. With all due respect: piss off. Is this a new sport in #d-d or something like that? I read that entry as "the new upstream version fixes the problem reported in #193497", and looking at the BTS that is exactly its meaning. I'm sure there's a thousand better things to do with your time (hint: fixing bugs) other than nitpicking at changelog entries because they don't include the last period and last comma you want them to. This changelog-policying camp is becoming very very counter-productive. Marcelo
Re: Bug#193497: marked as done (svtools: svsetup uses bashism "echo -e")
On Sun, Jun 01, 2003 at 06:34:49PM +0200, Sam Hocevar wrote: >Now maybe public humiliation and eternal ridiculation on > debian-devel is not necessary I can't care less for this "humiliation and ridiculation". I care about the fact that S/N in d-d is already bad enough without having to watch (out for) these pissing contests. People, if taunting is your game, go make a webpage and call it the DD hall of shame (or whatever else tickles you), where folks who care for this kind of thing can hit reload to death. I'd really rather not killfile 'Re: Bug#\d+: marked as done' on d-d. > But I think it can be still useful to send the authors of such > changelogs a courteous private request to read the Developer's > Reference, section 6.3.3, which will certainly improve the overall > quality of Debian, with the additional benefit of not annoying this > mailing-list. By all means. Marcelo
Re: ATI Linux Driver Packages
On Mon, Jun 02, 2003 at 05:34:57PM +1000, Daniel Stone wrote: > Uhh, that's utterly incorrect. My Radeon 9000 has out-of-the-box 3D > support, as do original Radeons, and all Radeon 7xxx, 8xxx, and > 9[01]00 cards. The 9200 *may*, but I'm unsure. Hell, GATOS will even > give you VIVO support. The reason why you only get FireGL drivers is > because you don't *need* those drivers for the cards I mentioned > above. There's 3D support and there's 3D support. The r200 has something close to 60 million transistors. That's twice as many as the r100. A large part of this difference comes from the programmability of the r200. The DRI drivers support most of the functionality present in the r100 chip, but most of the new functionality introduced by the r200 is not really supported. The gap is much wider in the case of the r300. So, you are right as long as you don't intend to use the functionality the newer chips provide. > As for support, I've had pretty amazing support from ATI. ATI have > developer contacts who regularly feed patches into XFree86 upstream > and packagers (the entire 030 patch series was sent through ATI), and > they have the standing offer I mentioned above. The only thing > preventing capital-F-Free drivers being written right now is DRI > developer time constraints, AIUI. That's right. Marcelo
Re: package naming
Hi, On Mon, Jun 02, 2003 at 03:15:19PM -0400, Deedra Waters wrote: > I've been working on the package "kernel-patch-speakup" which has a > source package called speakup-cvs and produces the binary called > kernel-patch-speakup_20021221-1_all.deb, well, there is a stable > version of speakup that I'd like to package and have it keep the > kernel-patch-speakup name. This source package is called speakup, and > produces a similar binary called "kernel-patch-speakup_1.5-1_all.deb" > The problem currently is that the new source package produces a > binary package which already exists, and is generated by a different > source package I am not sure I understand why that's a problem. The only thing you have to take into account is adding an epoch to the new kernel-patch-speakup, since its old version 20021221-1 is newer than its new version 1.5-1. That is, you have to use 1:1.5-1 for the new version. In short: Source: speakup Version: 1:1.5-1 this produces the package kernel-patch-speakup Source: speakup-cvs Version: 20021221-1 this produces the package kernel-patch-speakup-cvs The epoch is necessary if you really want people to "upgrade" from the old CVS package to the new stable package. I see the package was not present in woody, so it's not a problem for people upgrading across Debian releases. Marcelo
Re: Managing package sources with subversion?
On Wed, Jun 04, 2003 at 01:47:28AM +1200, Carey Evans wrote: > % svn ls file:///home/repos/debian/tn5250 > branches/ > debian/ > tags/ > trunk/ > vendor/ > % svn ls file:///home/repos/debian/tn5250/debian > 0.16.5-1/ > 0.16.5-2/ > 0.16.5-3/ > 0.16.5-4/ > 0.16.5-5/ > % svn ls file:///home/repos/debian/tn5250/vendor > 0.16.5/ > current/ what's current? (in the context of svn, it's obvious that current is the current upstream version) I see you have only one upstream version. Any experience with importing and/or merging new upstream sources? A few small attempts at this exploded in my face... but this was some months ago, so things might have changed in the meantime. Marcelo
Re: buildd failure
On Tue, Jun 03, 2003 at 10:35:51AM -0400, Matt Zimmerman wrote: > On Tue, Jun 03, 2003 at 12:31:42PM +0200, Attila SZALAY wrote: > > > What can I do with this (from packages.qa.debian.org): > > > > # 42 days old (needed 10 days) > > # out of date on hppa: libzorpll, libzorpll-dev (from 2.0.5.2-1) > > > > This is with package libzorpll. > > Go to buildd.debian.org, read the log and find out what happened. For hppa: * 1.5.55-1 (latest build at Nov 18 15:01: maybe-failed) * 2.0.5.2-1 (latest build at Mar 23 17:18: maybe-successful) For alpha: * 1.5.55-1 (latest build at Nov 19 02:02: maybe-failed) * 1.5.57-1 (latest build at Nov 19 19:00: maybe-failed) * 2.0.1.3-1 (latest build at Nov 25 08:33: maybe-successful) * 2.0.5.2-1 (latest build at Nov 27 03:31: maybe-successful) * 2.0.26.4-1 (latest build at Apr 21 15:11: maybe-successful) Now, what does that mean? -m.
Re: texmf.cnf again
On Wed, Jun 04, 2003 at 01:01:18AM -0500, Manoj Srivastava wrote: > It is an either or situation -- give us your configuration > files, or forever lose out on any configuration change the > maintainers do, even though that shall break your packages. Sure, I wasn't claiming it's perfect. It's just better than before, this time you have the chance that you don't want your local modifications overwritten at seemingly random times. My point is that given the way the question is written, its priority and default answer seem to counter its purpose. Marcelo
Re: Bug#193497: marked as done (svtools: svsetup uses bashism "echo -e")
On Wed, Jun 04, 2003 at 12:34:43AM -0500, Manoj Srivastava wrote: > > I read that entry as "the new upstream version fixes the problem > > reported in #193497", and looking at the BTS that is exactly its > > meaning. > > I thinik a good changelog should not require one to go off to > an external document, remotely located, to determine what the change > was. Uh? less /usr/share/doc/package/changelog.gz That ain't what I call "remote". But yes, we should stick to our long standing tradition of good and informative changelogs. For example: * DISCLAIMER: All three of the above changelog entries did in fact change the state of the files in this source. It is the opinion of the maintainer (hereto after refered to as GOD), that the changes made do in fact make the package(s) better. GOD does not warantee that these changes will make your life (be it sex life, or no life) better. GOD does guarantee that you (hereto after refered to as NON-DIETY) will gain great wisdom simply by using this(these) package(s). The NON-DIETY shall not, in any event, hold GOD responsible for misreadings of these statements. * Ok, the 51 pages of flaming in tis bug report leads me to believe that this will never be resolved in glibc. IMO, it is up to the programmer to be smart enough to check these things (where it matters). I am closing this bug report on the precedence that it is not really a bug because current functionality meets specs (and this bug report would break that compatibility). This entire bug report should be archived all on it's own. Hell, it should have it's own BTS just to track the conversation. closes: #28251 Joking aside, I'm not advocating for uninformative changelogs. I'm asking this particular pissing contest to be taken out of d-d (taking the _other_ pissing contests out of d-d would be a plus, but that wouldn't be d-d anymore, would it?) > This is not dotting i'sand crossing t's. this is information > that is inherent to a changelog; and writing poer changelogs must be > encouraged. Sure. You are welcomed to use @packages.debian.org for that. Marcelo
