Gunnar Wolf wrote:
> Maybe we should ask the user at first boot if he wishes to use tasksel,
> dselect, aptitude or none-of-the-above, instead of going just tasksel
> and dselect...
Maybe we should look at a current install of debian before posting to
-devel.
--
see shy jo
signature.asc
Descri
On Wed, Oct 08, 2003 at 12:24:37AM +1000, Kim Lester wrote:
> There is no way to verify/correct the MODE, USER, GROUP, TYPE
> of any files installed in a pkg.
> If I am wrong please point out where, with an installed pkg
> (and preferably without having a copy of the .dpkg around)
> once can tell
On Tue, Oct 07, 2003 at 06:07:58PM -0400, Marco Paganini <[EMAIL PROTECTED]>
was heard to say:
> On Tue, Oct 07, 2003 at 05:57:42PM -0400, Daniel Burrows wrote:
>
> > > That would not be a problem, as no other program imports ask.py...
> >
> > Are you confident that no other program will ever
Steve Langasek <[EMAIL PROTECTED]> writes:
> On Mon, Sep 15, 2003 at 01:24:11PM -0500, Manoj Srivastava wrote:
>> On Mon, 15 Sep 2003 10:37:48 -0500, Steve Langasek <[EMAIL PROTECTED]> said:
>
>> > There is a distinct difference between recognizing what is missing
>> > from a description, and bei
Hi,
> > Yes. "ask.py" is just the main executable. It imports all the other modules
> > (which have the .py extension and should be in /usr/lib/ask or something).
>
> That'd be /usr/share (lib is for arch-dependant data, see FHS)
Oops, sorry! Slippery fingers. I meant /usr/share...
Regards,
Pag
On Tue, Oct 07, 2003 at 05:48:17PM -0400, Marco Paganini <[EMAIL PROTECTED]>
was heard to say:
> Hi Daniel,
>
> > I think it's worth pointing out that if a file called "ask.py" is in
> > /usr/bin, the statement:
> >
> > import ask
> >
> > from a Python program in /usr/bin which hasn't modif
On Tue, Oct 07, 2003 at 05:57:42PM -0400, Daniel Burrows wrote:
> > That would not be a problem, as no other program imports ask.py...
>
> Are you confident that no other program will ever want to "import ask"?
Yes. "ask.py" is just the main executable. It imports all the other modules
(which
Hi Daniel,
> I think it's worth pointing out that if a file called "ask.py" is in
> /usr/bin, the statement:
>
> import ask
>
> from a Python program in /usr/bin which hasn't modified its sys.path
> will, unless I am terribly confused, pick up ask.py instead of whatever
> module it was looki
Hi Marcello,
> > Euh, I think you messed up. Marco *is* upstream.
>
> That doesn't preclude whackig upstream with a cluebat :-) Here, he can
> use mine.
I tried whacking myself repeatedly with the cluebat. Unfortunately, it was
not as effective as whacking someone else. But I think I got th
Package: wnpp
Version: unavailable; reported 2003-10-07
Severity: wishlist
* Package name: ps2eps
Version : 1.47
Upstream Author : Roland Bless <[EMAIL PROTECTED]>
* URL :
http://www.telematik.informatik.uni-karlsruhe.de/~bless/ps2eps.html
* License : GPL
De
Processing commands for [EMAIL PROTECTED]:
> tag 213822 moreinfo
Bug#213822:
=?iso-8859-15?q?general=3A_keymap_be-latin1_doesn=27t_allow_typing_=5C_or?=
=?iso-8859-15?q?_=40_by_using_AltGr=0D=0AThis_week_I_installed_knoppix_=28v3?=
=?iso-8859-15?q?=2E2=29_on_the_computer_of_a_friend=2E=0D=0AYes
On Tue, Oct 07, 2003 at 02:58:25PM -0500, Branden Robinson wrote:
> I think the problem with .la files may be solvable by updating
> Build-Depends and -dev packages' dependencies to refer to libxrender-dev
> (>= 0.8.3-1), and/or libraries that are rebuilt against that version of
> libxrender-dev.
On Tue, Oct 07, 2003 at 10:35:40AM -0700, Carl B. Constantine wrote:
> I think there used to be a packaged called gnucash-sql which allowed
> gnucash to save data to a postgres database. That package doesn't seem
> to exist any longer. Has the functionality of gnucash-sql been merged
> into gnucash
tag 213822 moreinfo
thanks
Jan,
If I understand correctly, your keyboard doesn't work right, but the rest of
the system is OK.
Are there other keys with AltGr that work? For example, can you type a curly
brace '{' (AltGr-9)?
If you try to upgrade your system (with apt-get) it doesnt't instal
On Tue, Oct 07, 2003 at 03:40:18AM -0500, Chris Cheney wrote:
> On Tue, Oct 07, 2003 at 10:26:45AM +0200, Marcelo E. Magallon wrote:
> > On Tue, Oct 07, 2003 at 01:33:01AM -0500, Chris Cheney wrote:
> >
> > > Does anyone happen to know why .la files hardcode the paths to .la
> > > files that the
also sprach Anthony DeRobertis <[EMAIL PROTECTED]> [2003.10.07.1935 +0200]:
> >It has existed in the freeswan patch for a while!
>
> Let's be serious, FreeS/WAN has serious issues! Being at war with the
> kernel routing machinery, for example.
Alright, I give you that. But it works.
--
Please
On Tue, 2003-10-07 at 09:51, Colin Watson wrote:
> On Tue, Oct 07, 2003 at 09:48:32AM -0400, Greg Folkert wrote:
> > Would it NO doubt make entirely MUCH more sense, to only have to D/L the
> > Source Code once.
>
> Would it be POSSIBLE to LOSE the Zippy-style CAPITALIZATION, please?
Would it be
On Monday, Oct 6, 2003, at 18:58 US/Eastern, Adam McKenna wrote:
I don't see how the package being in unstable affects any part of this
argument. Will the feature backport be less desirable when the
kernel-source package is released in a stable revision of Debian?
The whole point of not doing feat
Björn Stenberg writes:
> 2) How is meta package versioning handled? The gcc-defaults package, version
> 1.9, is the only package providing the gcc binary (without -version suffix) of
> which many packages require version >= 2.95.
gcc-defaults implements it's own version handling. see the source.
On Monday, Oct 6, 2003, at 16:20 US/Eastern, martin f krafft wrote:
It has existed in the freeswan patch for a while!
Let's be serious, FreeS/WAN has serious issues! Being at war with the
kernel routing machinery, for example.
I think there used to be a packaged called gnucash-sql which allowed
gnucash to save data to a postgres database. That package doesn't seem
to exist any longer. Has the functionality of gnucash-sql been merged
into gnucash proper?
--
.''`. Carl B. Constantine
: :' : [EMAIL PROTECTED]
`.
On Tue, Oct 07, 2003 at 05:23:32PM +0200, Björn Stenberg wrote:
> Steve Langasek wrote:
> > Hypothetical example:
> >
> > 29 packages wait on (151 packages are stalled by) libxml2. This package
> > is too young, and should be a valid candidate in 8 days.
> >
> > Suppose that the libxml2 source p
Marco Paganini wrote:
> I'm packaging a Python program called "ask" for distribution. Currently,
> the main executable is called "ask.py". It seems unusual (and why not say,
> *ugly*) to have the language extension added to the program, but in this
> case, it was a deliberate decision to avoid
Package: wnpp
Version: unavailable; reported 2003-10-07
Severity: wishlist
* Package name: r-cran-qtl
Version : 0.9.7-21
Upstream Author : Karl W. Broman <[EMAIL PROTECTED]>, Hao Wu <[EMAIL
PROTECTED]>
* URL : http://www.biostat.jhsph.edu/~kbroman/qtl/index.html
* Lic
Steve Langasek wrote:
> Hypothetical example:
>
> 29 packages wait on (151 packages are stalled by) libxml2. This package
> is too young, and should be a valid candidate in 8 days.
>
> Suppose that the libxml2 source package provided not only the
> libxml2-python2.3 binary package, but also a li
On Mon, Oct 06, 2003 at 08:26:44PM -0400, Marco Paganini <[EMAIL PROTECTED]>
was heard to say:
> I'm packaging a Python program called "ask" for distribution. Currently,
> the main executable is called "ask.py". It seems unusual (and why not say,
> *ugly*) to have the language extension added to t
On Wed, Oct 08, 2003 at 12:24:37AM +1000, Kim Lester wrote:
> There is no way to verify/correct the MODE, USER, GROUP, TYPE
> of any files installed in a pkg.
That appears to be the case, partly because permissions may be changed
from those files which are contained withing the .deb file via t
On Tue, Oct 07, 2003 at 09:30:56AM +0100, Scott James Remnant wrote:
> On Tue, 2003-10-07 at 07:33, Chris Cheney wrote:
>
> > Does anyone happen to know why .la files hardcode the paths to .la files
> > that they depend on?
> >
> To guarantee that you don't end up linking with something totally
>
The comments about debsums are useful and contribute
to the whole issue butthey still miss one of my
key points/queries.
There is no way to verify/correct the MODE, USER, GROUP, TYPE
of any files installed in a pkg.
If I am wrong please point out where, with an installed pkg
(and preferably witho
> > 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
On Tue, Oct 07, 2003 at 09:48:32AM -0400, Greg Folkert wrote:
> But, this would alleviate SOME of the problems. This would be NO DOUBT
> very helpful. The Binary Kernel (as in the archives could have any an
> all patches you see fit Herbert)
>
> Would it NO doubt make entirely MUCH more sense, to
On Tue, Oct 07, 2003 at 11:11:35AM +0200, Marcelo E. Magallon wrote:
> > What's more of a problem here is that libtool actually links
> > dependency libraries of dependencies ... it's something I've been
> > working on for a while.
> That's a bug, not a feature. From libtool's perspective at
On Sat, Oct 04, 2003 at 01:46:08AM +0200, Nicolas Boullis wrote:
> Moreover, that does not answer to my real question: is there a good
> reason not to implement such an extended syntax for versionned
> relationships.
Probably not; but there needs to be a good reason to do it. It has to
be imple
On Mon, 2003-10-06 at 15:39, martin f krafft wrote:
> also sprach Eduard Bloch <[EMAIL PROTECTED]> [2003.09.22.1207 +0200]:
> > Let's create a package called "linux-2.4.22" or
> > "linux-2.4.22-pure-vanilla-source-for-you-to-patch" with a script which
> > does exactly this.
>
> I oppose. Let's get
Chris writes:
> $ ls /usr/bin/*openoffice*
> /usr/bin/openoffice
> What is dumb about that? The thread is about naming of files within
> /usr/bin.
Since the package is named openoffice.org supposedly for trademark reasons
I assumed that the binary was as well.
--
John Hasler
[EMAIL PROTECTED] (
On Tue, Oct 07, 2003 at 01:24:37PM +, Robert Millan wrote:
> > > I'm packaging a Python program called "ask" for distribution.
> > > Currently, the main executable is called "ask.py".
> >
> > a. Whack upstream with a cluebat.
>
> Euh, I think you messed up. Marco *is* upstream.
>
> So perh
> > I'm packaging a Python program called "ask" for distribution.
> > Currently, the main executable is called "ask.py".
>
> a. Whack upstream with a cluebat.
Euh, I think you messed up. Marco *is* upstream.
On the other hand, Marco being upstream defeats John's argument:
> Leave it. The pro
On Mon, Oct 06, 2003 at 07:50:07PM -0500, John Hasler wrote:
> Besides, if dumb names were a problem we'd do something about
> openoffice.org.
$ ls /usr/bin/*openoffice*
/usr/bin/openoffice
What is dumb about that? The thread is about naming of files within
/usr/bin.
Chris
pgpsBIj7fhkCn.pgp
D
On Tue, Oct 07, 2003 at 09:30:56AM +0100, Scott James Remnant wrote:
> On Tue, 2003-10-07 at 07:33, Chris Cheney wrote:
>
> > Does anyone happen to know why .la files hardcode the paths to .la files
> > that they depend on?
> >
> To guarantee that you don't end up linking with something totally
>
> What's more of a problem here is that libtool actually links
> dependency libraries of dependencies ... it's something I've been
> working on for a while.
That's a bug, not a feature. From libtool's perspective at least.
You have to keep in mind that libtool is designed to work around
ex
On Tue, Oct 07, 2003 at 10:26:45AM +0200, Marcelo E. Magallon wrote:
> On Tue, Oct 07, 2003 at 01:33:01AM -0500, Chris Cheney wrote:
>
> > Does anyone happen to know why .la files hardcode the paths to .la
> > files that they depend on?
>
> Anal-retentiveness wrt using the exact same library o
On Tue, 2003-10-07 at 07:33, Chris Cheney wrote:
> Does anyone happen to know why .la files hardcode the paths to .la files
> that they depend on?
>
To guarantee that you don't end up linking with something totally
different if the app being compiled happens to have a different search
path.
What
Bao C. Ha <[EMAIL PROTECTED]> wrote:
>
> If I want both the freeswan module capability and IPVS, how should
> I proceed.
If all you need is to run freeswan, then you can unapply the IPSEC patch,
and simply use KLIPS.
If you need the new stack, then you will need to fix the conflicts.
It should
also sprach Steve Langasek <[EMAIL PROTECTED]> [2003.10.07.0104 +0200]:
> As stated above, this is not a reasonable restriction. An
> arbitrary kernel patch package might conflict with *any* changes
> made to the kernel-source package, including simple security
> fixes.
A simple fix is easier to
On Tue, Oct 07, 2003 at 01:33:01AM -0500, Chris Cheney wrote:
> Does anyone happen to know why .la files hardcode the paths to .la
> files that they depend on?
Anal-retentiveness wrt using the exact same library originaly used.
> This is about to bite Debian hard with some of the XFree86 lib
On Mon, Oct 06, 2003 at 08:26:44PM -0400, Marco Paganini wrote:
> I'm packaging a Python program called "ask" for distribution.
> Currently, the main executable is called "ask.py".
a. Whack upstream with a cluebat.
b. Repeat a.
c. What happens when the program gets reimplemented in another
Does anyone happen to know why .la files hardcode the paths to .la files
that they depend on?
For example:
dependency_libs=' -lm -L/usr/lib /usr/lib/libogg.la'
This is about to bite Debian hard with some of the XFree86 libraries
moving to /usr/lib.
Chris Cheney
---
# libvorbis.la - a libtool
On Mon, 2003-10-06 at 21:19, martin f krafft wrote:
> I'd appreciate if you kept your opinions to yourself,
>
Can you do the same?
Scott
(Unsigned as I've already packed my keyring for Linux Expo today)
--
Have you ever, ever felt like this?
Had strange things happen? Are you going round the
48 matches
Mail list logo
