Package: wnpp
Severity: wishlist
Owner: Marcelo Jorge Vieira
X-Debbugs-CC: debian-devel@lists.debian.org
* Package name: node-shelljs
Version : 0.4.0
Upstream Author : Artur Adib
* URL : http://github.com/arturadib/shelljs
* License : BSD*
Programming Lang
something in the dependency chain pulls Ruby into the system.
Marcelo
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130130123335.GA30105@esk
Package: general
Severity: normal
Dear Maintainer,
*** Please consider answering these questions, where appropiate ***
* What led up to the situation?
* What exactly did you do (or not do) that was effective (or
ineffective)?
* What was the outcome of this action?
* What outcome
e of this, since it's not
usual to have the SONAME in a different directory.
My ₡0.02,
Marcelo
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110101221737.ga17...@esk
Package: wnpp
Severity: wishlist
Owner: Marcelo Jorge Vieira (metal)
* Package name: libjs-xmlextras
Version : not mentioned
Upstream Author : Erik Arvidsson
* URL : http://webfx.eae.net/dhtml/xmlextras/xmlextras.html
* License : Apache Software License 2.0
Package: wnpp
Severity: wishlist
Owner: Marcelo Jorge Vieira (metal)
* Package name: pesto
Version : 13
Upstream Author : Oliver Cope
* URL : http://pesto.redgecko.org/
* License : BSD
Programming Lang: Python
Description : is a library for Python web
of dynamic web applications.
Featuring a unique, easy-to-use toolkit for class-driven
development and the nicest Ajax library around, Prototype
is quickly becoming the codebase of choice for web application
developers everywhe
--
Marcelo Jorge Vieira (metal)
metaldot - http
Package: wnpp
Severity: wishlist
Owner: Marcelo Jorge Vieira (metal) <[EMAIL PROTECTED]>
* Package name : libjs-scriptaculous
Version: 1.8.1
Upstream Author: Thomas Fuchs
* URL: http://script.aculo.us/
* License: MIT-style license
Description: is
Package: wnpp
Severity: wishlist
Owner: Marcelo Jorge Vieira (metal) <[EMAIL PROTECTED]>
* Package name : jsjac
Version: 1.2.1
Upstream Author: Stefan Strigler <[EMAIL PROTECTED]>
* URL: http://zeank.in-berlin.de/jsjac
* License: LGPL
in PHP
SimplePie is a very fast and easy-to-use class, written in PHP, that
puts the ‘simple’ back into ‘really simple syndication’. Flexible enough
to suit beginners and veterans alike, SimplePie is focused on speed,
ease of use, compatibility and standards compliance.
--
Marcelo Jorge
. It's just plain HTML/JavaScript.
MUCkl uses [1]Jabber technology to handle all communication. It
let's you connect to any predefined [2]MUC-based chat room.
[1] http://www.jabber.org
[2] http://www.jabber.org/jeps/jep-0045.html
--
Marcelo Jorge Vieira (metal)
metaldot - htt
s following html frames (added v0.92)
* supports passing cookies on redirects (added v0.92)
--
Marcelo Jorge Vieira (metal)
metaldot - http://metaldot.alucinados.com
jabber - [EMAIL PROTECTED]
signature.asc
Description: This is a digitally signed message part
ar so I
> am interested in a package.
No... thanks,
--
Marcelo Jorge Vieira (metal)
metaldot - http://metaldot.alucinados.com
jabber - [EMAIL PROTECTED]
signature.asc
Description: This is a digitally signed message part
retitle 440602 ITP: tinytinyrss -- Web-based news reader
owner 440602 !
--
Marcelo Jorge Vieira (metal)
metaldot - http://metaldot.alucinados.com
jabber - [EMAIL PROTECTED]
signature.asc
Description: This is a digitally signed message part
ver 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]
Como consigo lista de mails de uruguay y/o del
mundo?
Como te lo pago?
Soy de paysandu uruguay
I'll try that on the hardware I have (i815 I think).
> The attached patch adds the IMO appropriate Conflicts:, Replaces: and
> Provides: for libgl1-mesa-dri{,-dev}.
Oh, thanks, I forgot those, too :-P
> > And co-maintaining is always welcomed.
>
> Okay, do you inten
legacy
tarballs are sometimes the same file, sometimes not), but taking into
account that the binary packages are *much* larger than the source I
don't think that's something to gripe about.
Cheers,
--
Marcelo
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
email got lost :-)
Please do check the 6.3.2 packages, I suspect we have fixed the same
things each on our own. I introduced another of those .map hacks for
the drivers. I also tried to make it easier to disable building some
of the targets, guessing that other distros aren't interested in
x27;t mind co-maintaining or something. No
> request, just an offer.
Since Mesa suddenly includes a lot more drivers that I can't test, I'd
really appreciate even a heads up "it's working fine with ".
And co-maintaining is always welcomed.
--
Marcelo
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
prepare for the
> X11R6.9/X11R7.0 release. IIRC X11R6.9 and X11R7.0 will use an
> installed mesa package to provide OpenGL functionality and will not
> need it's own copy of mesa anymore.
Probably, which in itself is not wrong.
--
Marcelo
--
To UNSUBSCRIBE, email to [EMAIL PR
the current (6.8) and future (6.9, 7.0) x.org server.
> Could someone with a deeper insight enlighten me?
I'm sure Michel has an informed opinion, too.
My interest in the mesa package comes from the fact that I develop
OpenGL-based applications, which is why I picked it up when it was
orphaned and why I've been maintaining it for the last few years.
--
Marcelo
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
On Mon, Aug 22, 2005 at 01:13:08AM +0200, Petter Reinholdtsen wrote:
> +for pid in $pids ; do
> +wait $pid
> +done
Isn't just:
wait
enough?
--
Marcelo
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
wiki... there was a time, not so
long ago, when a mailing list and some sort of repository for the
source code was everything a group of programmers needed to get on
hacking...
/me waits for the compulsory "both ways! uphill!" remark...
SCNR,
Marcelo
--
To UNSUBSCRIBE, email
Package: wnpp
Severity: wishlist
Owner: "Marcelo E. Magallon" <[EMAIL PROTECTED]>
* Package name: libdrm
Version : 1.0.2
Upstream Author : DRI Developers
* URL : http://people.freedesktop.org/~ajax/libdrm/
* License : BSD-like
Description
h that functionality. If
you really want to have a non-maintained non-supported script in your
path, do as I suggest above.
--
Marcelo
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
arm hppa i386 ia64 m68k mips mipsel powerpc s390 sparc.
--
Marcelo
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
d add a link to your updated graph
> from http://people.debian.org/~mfurr/gxx/>. It would make sure
> at least I find it when I need it.
Agreed.
--
Marcelo
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
On Sun, Aug 07, 2005 at 10:59:51AM -0500, Steve Greenland wrote:
> On 06-Aug-05, 17:42 (CDT), "Marcelo E. Magallon" <[EMAIL PROTECTED]> wrote:
> > That said, what exactly is the problem kernel-image-x.y.z
> > providing a kernel image for *bsd or hurd or
"rationale". I did find the obvious "where does 'kernel-image'
leave Foo Kernel?" which still doesn't beat the two arguments against
the change that I mention above.
That said, what exactly is the problem kernel-image-x.y.z providing a
kernel image for *bs
On Mon, Aug 01, 2005 at 11:22:19AM +0200, Enrico Zini wrote:
> > libtagcoll0, Enrico Zini <[EMAIL PROTECTED]>
>
> Already asked for removal, now supserseded by libtagcoll1-{dev,pic}.
I added this to the exclusion list.
Marcelo
--
To UNSUBSCRIBE, email to [EMAIL
On Mon, Aug 01, 2005 at 10:34:14AM +0200, Thomas Viehmann wrote:
> thanks for the list. Do you want updates?
Sure. Exclusions mostly. Whatever needs to be excluded from the list
because it doesn't need to be/won't be transitioned.
--
Marcelo
--
To UNSUBSCRIBE, email to [EM
On Sun, Jul 31, 2005 at 11:04:30PM -0600, Marcelo E. Magallon wrote:
> The attached list has been generated with an up to date Packages
> file for the following architectures: alpha arm hppa hurd-i386 i386
> ia64 m68k mips mipsel powerpc s390 sh sparc.
The list and script can be
On Mon, Jul 25, 2005 at 07:45:39PM -0600, Marcelo E. Magallon wrote:
> After some fiddling with AptPkg, my first cut at generating a list
> of packages ready to be transitioned is attached.
After getting fed up with AptPkg I rewrote the script in the attached
form. If you feed the
On Mon, Jul 25, 2005 at 08:39:26PM -0600, Marcelo E. Magallon wrote:
> A small parser that looks for extern "C", the "{" right after it and
> the matching "}" should make things much easier.
The attached script should work in most cases.
--
Marc
rmless. Let's say you do find something like:
extern void glEnableTraceMESA( GLbitfield mask );
_outside_ the extern "C" block... that is _not_ harmless.
A small parser that looks for extern "C", the "{" right after it and
the matching "}" should make things much easier.
--
Marcelo
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
is way too long, IMO. The longer this transition takes the
harder it gets to get out of this swamp. (And yes, that package of
mine on this list is already sitting on some upload queue)
Cheers,
Marcelo
P.S.: you need libapt-pkg-perl and libgraph-perl.
A Mennucc1 <[EMAIL PROTECTED]>
; needs to be fixed and set back to libglu1.
If someone knows of a case where this breaks, please speak up now.
Thanks,
--
Marcelo
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
d they run fine with other libGLUs compiled with gcc 3.3.
Marcelo
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
ility 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]
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]
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 depe
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
e 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]
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]
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.
ll 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]
eing 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]
$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]
n 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]
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&qu
sn'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]
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]
e 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&qu
s 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]
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 PROT
y 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]
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
t 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
ht to hear the jokes I get to hear once a month on the local
LUG meetings. Oh dear, next meeting is this saturday.
Marcelo
es
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
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 p
. (And no
"we will release in two years time" is not a release schedule in this
context).
Marcelo
ne , 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
tiple
> > 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
se 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
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
hat's what it takes.
This project is making a custom out of threating developers like crap.
Marcelo
k:
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
to take
into account to that ~/ is not unusually a shared resource.
Marcelo
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
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
e 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
hat 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
ower
consumption. One can only hope SGI will survive long enough...
Thanks for the info to both of you guys,
Marcelo,
wondering what do the MIPS folk do with Debian in the real world...
ne using MIPS processors which supposedly will be made
available with Linux on it in the future, yet it's already shadowed by
machines using AMD64 processors which happen to be available now and
where Linux runs now with support for all the functionality of the
hardware.
Just curious...
Marcelo
> But there is one thing to mention: development seems to be stalled
> for some time now, I can't complain about bugs though.
Take a look at kahakai: http://kahakai.sf.net/
--
Marcelo
to call these things would
be nice.
--
Marcelo
architectures don't have 2.4.22
packages? If you look at the list you'll notice sparc, hppa, ia64,
arm, m68k and s390 missing...
Just food for thought...
--
Marcelo
ion from Colin above, you forgot to answer
that.
> I don't feel it necessary. But this is not the first trivial
> maintainer issue I'm being pointed at in this ITP, and I'm getting
> the impression that some people are doing it deliberately.
Yes, Robert, join #we-r-out-to-get-robert (password is
debian-can't-handle-upgrades) and have some fun with us. Don't mind
the black choppers parked at the door.
--
Marcelo
for security related stuff and packages
> > autobuilded that way aren't automatically uploaded to the archive
> > (whatever the girl is called doesn't like packages without source,
> > and the security team doesn't like publishing security fixes
> > before the cat's out of the bag, so AFAIUI all this is handled
> > manually)
>
> Do you understand what "infrastructure problem" means?
AFAIUI this is not completely unintentional. Go talk to Matt Zimmerman
(or any other of security people) if you care.
> Of course I am. Aren't you asking the same question as often you
> want?
Because you haven't answered it in a satisfactory way, since you are
still not providing a characterization of your userbase. Saying "the
people who like FOO in a package" still doesn't say anything about
those people's needs (or actual existence for that matter). Want to
use precompiled modules? Install kernel-image-x.y.z-w-flavor and the
modules you want. Want to depend on Debian provided kernels and track
the current default? Install kernel-image-x.y-flavor. Want to have
custom kernels available as Debian packages? Use make-kpkg. Want to
use the good old make bzImage && make install? Go ahead. Who did I
left out who's not being addressed by the current solution and is
addressed by yours? Please show me that that set is larger than just
you.
--
Marcelo
situation with the current kernel packages is when you update between
package releases of the same kernel version, and the current kernel
packages make plenty of noise in that situation.
--
Marcelo
y of doing.
And you are welcome to do whatever you want in your $HOME. I'm not
telling you what you can and can't do with your time. But placing the
package in the distribution is a different thing, there you _are_
duplicating effort.
> > I think it's more than justified to ask you who you think your
> > users are.
>
> Sure. My users are those who like the advantages described in:
>
> http://lists.debian.org/debian-devel/2003/debian-devel-200311/msg00414.html
Sure, you are free to keep quoting that URL as often as you want (which
still doesn't answer the question in a satisfactory way), but that
doesn't change the fact that the objection to your ITP still stands.
> Or did you think I pretend to insert my package into stable directly?
Gee, it didn't occur to me that your first upload was going to be to
unstable or experimental... /like every other maintainer does with
every other package in this project/.
--
Marcelo
you intend to replace kernel-image-* or _do something_ about that, too.
> I don't see why should I do that. Enumerating the advantages is quite
> enough. Some people will appreciate them, and some not.
You are duplicating effort by providing something that already exists.
I think it's more than justified to ask you who you think your users
are.
> Herbert said what he said, period. Wether my package is suitable for
> stable or not is behind the scope of his mail.
Oh, then keep your packages in p.d.o/~rmh/whatever please. Because
that's Debian hosting them. Which is what Herbert said, nothing more,
nothing less.
--
Marcelo
icular
I wonder if he realizes that once a package is shipped with a stable
release, getting rid of it is a PITA. Herbert didn't actually say he'd
like to see this as part of a release (he only said "hosting"
actually), but I'll give you the benefit of doubt on that.
> > So, your package _can't_ be the default kernel package, because
> > that needs to be supported on all architectures the installer
> > supports. Which makes me wonder again: what is your target
> > userbase?
>
> Those who like the advantages described in:
>
> http://lists.debian.org/debian-devel/2003/debian-devel-200311/msg00414.html
Oh, come on, did you even read the question?
Marcelo
take a good
deal of talking to convince me that that _per se_ is better.
> As I said a thousand times, if an architecture is unsupportable, not
> supporting it is an option.
So, your package _can't_ be the default kernel package, because that
needs to be supported on all architectures the installer supports.
Which makes me wonder again: what is your target userbase?
--
Marcelo
al kernel image packages maintainer and work something out.
This creates _more_ work for everybody. What do you want to do with
binaries of kernel modules? Have more duplication of effort?
Marcelo
On Thu, Nov 06, 2003 at 11:31:30AM +0100, Sebastian Henschel wrote:
> in short: i want your blessing. :)
Go, go, go!
Just package the thing as wmacpi and be happy.
--
Marcelo
he the
motherboards based on this chipset use aren't supported until
2.4.23-preY (Y around 3, IIRC). I remember having had _a lot_ of
trouble with DMA, but IIRC the thing did boot with older kernels.
--
Marcelo
ge -F Build-Depends docbook-xml /path/to/Sources
$ man grep-dctrl
for more details.
--
Marcelo
ich would be closer
to what you wrote, but not quite)
What we ship in the packages is a symbolic link $SONAME -> $FILENAME.
--
Marcelo
> > a. Whack upstream with a cluebat.
>
> Euh, I think you messed up. Marco *is* upstream.
That doesn't preclude whackig upstream with a cluebat :-) Here, he can
use mine.
--
Marcelo
stuff like that. The other
option of course is to actually fix libtool to do the right thing on
gnu-linux systems. But that's a sizeable ammount of work.
--
Marcelo
e XFree86 libraries
> moving to /usr/lib.
Can you be more specific?
--
Marcelo
e program gets reimplemented in another
language?
d. Keep repeating a.
--
Marcelo
soanl debian experience.
You are saying that MDI in a window-less text environment is...
intuitive? Can I have the space-time coordinates of your alternate
reality?
--
Marcelo
)-$(*) && CFLAGS="$(CFLAGS_$(*))" ./configure
$(CFGFLAGS_$(*))
$(MAKE) -C $(SRCDIR)-$(*)
touch $@
It makes debugging so much easier...
--
Marcelo
But gnumeric doesn't let
me edit the accels either. And gvim (of all things!) seems to obey
them, but it at least has the decency to complain when I try to change
the accels the "GTK+ way".
Marcelo
3-08-26 13:47:34 ./lib/libc-2.3.2.so
$ dpkg --contents libc6.1_2.3.2-4_alpha.deb | grep /lib/libc-2.3.2.so
-rwxr-xr-x root/root 1586408 2003-08-26 19:47:37 ./lib/libc-2.3.2.so
$ dpkg --contents libc6.1_2.3.2-4_ia64.deb | grep /lib/libc-2.3.2.so
-rwxr-xr-x root/root 2391480 2003-08-26 19:10:55 ./lib/libc-2.3.2.so
--
Marcelo
Package -F Architecture -v all | wc -l
7628
A lot of that is due to the gazillion kernel flavors and their modules,
some compilers, some sensors and sensor-related stuff, a few acpi
packages, old libc5 stuff, and the good old "uh?" stuff (firebird for
example).
--
Marcelo
1 - 100 of 295 matches
Mail list logo
