--- Robert Bihlmeyer <[EMAIL PROTECTED]> wrote: >
Michèl Alexandre Salim <[EMAIL PROTECTED]>
> writes:
>
> > Have not managed to package Pango - can anyone
> assist me in finding
> > out what is going wrong? Basically the package
> failed the install
> > stage of the rules script if installed usi
--- Sam Hartman <[EMAIL PROTECTED]> wrote: > >
"Michèl" == Michèl Alexandre Salim
> <[EMAIL PROTECTED]> writes:
> And if you come up with a clean solution for the
> changelog issue, I
> agree this is worth doing. If you do that, please
> let me know what
> your solution is.
>
As Richard Atter
On Mon, Jun 04, 2001 at 06:31:54PM +0100, Michèl Alexandre Salim wrote:
[debian/ in upstream makes maintaining package difficult]
> The reason I raise this issue in the first place is actually a
> notion that it would be nice for users wanting bleeding-edge
> software to update from CVS and just ru
On Tue, 5 Jun 2001 10:17:01 +0100, Julian Gilbey
<[EMAIL PROTECTED]> wrote:
>On Tue, Jun 05, 2001 at 11:01:22AM +0200, Marc Haber wrote:
>> >And if it's a wrapper
>> >script, wouldn't it be a lot better to have the wrapper in /usr/bin,
>> >with the real program called something like foo.real, and j
--- Tollef Fog Heen <[EMAIL PROTECTED]> wrote: > *
Christian Marillat
>
> | MAS> Indeed, but for package naming purpose I
> guess calling
> | MAS> them libglib2 and libgtk2 would work.
> |
> | I disagree. The API may change between 1.3.5 and
> 2.0
>
> Please LART upstream heavily and give the p
--- Josip Rodin <[EMAIL PROTECTED]> wrote: > On Sun,
Jun 03, 2001 at 11:40:26PM -0300, Henrique
> de Moraes Holschuh wrote:
> files there. Even if
> > upstream keeps its debian/ up-to-date, it will
> still cause you trouble if
> > you have to remove a file, as you'll need to
> either use dirty tr
Hello,
A brief follow-up to my post last weekend. The current
status of my test packages are as follows:
GLib - packages created. RFC - I am not a seasoned
developer (yet!), any advice more than welcome.
Gtk-doc - needed if you want to recompile GNOME CVS
modules (including GLib). I have package
On Mon, 4 Jun 2001 10:12:19 +0100, Julian Gilbey
<[EMAIL PROTECTED]> wrote:
>Why not just /etc/foorc or /etc/foo.conf or something like that?
Because the conffile is not a "real" conffile, but rather a shell
script being sourced in, and /etc/foo.conf will probably suggest that
this conffile is an
On Tue, 5 Jun 2001, Marc Haber wrote:
> I have a package with a library that needs to be entered to
> /etc/ld.so.preload. It is clear that this library needs to go in /lib
> rather than /usr/lib because there are systems that have /usr on a
> dedicated partition.
Are you sure that *every* program
Russell Coker <[EMAIL PROTECTED]> writes:
> On Monday 04 June 2001 00:59, Julian Gilbey wrote:
> > On Sun, Jun 03, 2001 at 02:37:19PM +0200, Russell Coker wrote:
> > > Another thing any package that depends on the creation of nodes under
> > > /dev MUST depend on "makedev | devfsd". People who ru
On Tue, 5 Jun 2001 15:32:25 +0200 (CEST), Simon Richter
<[EMAIL PROTECTED]> wrote:
>On Tue, 5 Jun 2001, Marc Haber wrote:
>> I have a package with a library that needs to be entered to
>> /etc/ld.so.preload. It is clear that this library needs to go in /lib
>> rather than /usr/lib because there are
I am not a Debian maintainer yet.
I signed up to become a Debian maintainer in order to maintain gphoto2,
and started the process of becoming one around January, but I could not
complete the "skill" tests due to lack of time and a publicly available
version of gphoto2, at that time.
So my applica
On Tue, 5 Jun 2001 09:34:37 +0100, Julian Gilbey
<[EMAIL PROTECTED]> wrote:
>> Because the conffile is not a "real" conffile, but rather a shell
>> script being sourced in, and /etc/foo.conf will probably suggest that
>> this conffile is an upstream feature.
>
>When you say "shell script", do you m
* Christian Marillat
| MAS> Indeed, but for package naming purpose I guess calling
| MAS> them libglib2 and libgtk2 would work.
|
| I disagree. The API may change between 1.3.5 and 2.0
GTK has a very, very broken versioning. There is no connection
between the soname of a library and the versio
On Tue, Jun 05, 2001 at 08:43:56AM +0200, Marc Haber wrote:
> On Mon, 4 Jun 2001 10:12:19 +0100, Julian Gilbey
> <[EMAIL PROTECTED]> wrote:
> >Why not just /etc/foorc or /etc/foo.conf or something like that?
>
> Because the conffile is not a "real" conffile, but rather a shell
> script being sourc
On Mon, Jun 04, 2001 at 10:31:18AM +0200, Marc Haber wrote:
> Hi,
>
> let's say I have a package foo with a binary foo. The author suggests
> the one should have a shell script wrapper to be able to call the foo
> binary with the appropriate options. I want to do so in my package.
>
> - Have the
> "Michèl" == Michèl Alexandre Salim <[EMAIL PROTECTED]> writes:
>>
Michèl> The reason I raise this issue in the first place is
Michèl> actually a notion that it would be nice for users wanting
Michèl> bleeding-edge software to update from CVS and just run
Michèl> debian/ru
Marc Haber wrote:
> This is the way to do it for an init script. Is it OK to have a file
> in /etc/default that does not provider defaults for an init script
> but for an executeable called by users?
I don't know. I don't see a lot of advantage over just putting the
conffile in /etc.
There is so
Marc Haber <[EMAIL PROTECTED]> writes:
> (2)
> Ask the user if I should add the lib to /etc/ld.so.preload in the
> postinst and automatically remove the entry in prerm? Does order in
> /etc/ld.so.preload matter?
I'd guess that order is significant if more than one preloaded lib
defines the same s
> "Michèl" == Michèl Alexandre Salim <[EMAIL PROTECTED]> writes:
Michèl> Hello, A general observation of Unix programs in general -
Michèl> a lot more of them come with RPM spec files, even
Michèl> generates them automatically from a spec.in file, than
Michèl> with debian scrip
On Tue, Jun 05, 2001 at 04:40:06PM +0200, Marc Haber wrote:
> >On Tue, Jun 05, 2001 at 11:01:22AM +0200, Marc Haber wrote:
> >> >And if it's a wrapper
> >> >script, wouldn't it be a lot better to have the wrapper in /usr/bin,
> >> >with the real program called something like foo.real, and just the
On Tue, Jun 05, 2001 at 11:01:22AM +0200, Marc Haber wrote:
> > If you want to
> >make it clear that it's a Debian-specific thing, surely you can put a
> >note to that effect at the top of the file?
>
> Never underestimate the user's stupidity.
I don't, but how will the location and user's (sysad
Michèl Alexandre Salim <[EMAIL PROTECTED]> writes:
> Have another problem though, when building libpango0 dpkg-gencontrol
> complained thus:
>
> dpkg-gencontrol: warning: unknown substitution
> variable ${shlibs:Depends}
The line
dh_shlibdeps -plibpango$(version)
should generate either s
I have a package with a library that needs to be entered to
/etc/ld.so.preload. It is clear that this library needs to go in /lib
rather than /usr/lib because there are systems that have /usr on a
dedicated partition.
But how do I handle the entry to /etc/ld.so.preload? There are
packages that lea
Debian Mentors:
I am looking for a sponsor/advocate for becoming a debian developer. I am
packaging misterhouse, a home automation package written in perl. I have
signed up at http://www.internatif.org/bortzmeyer/debian/sponsor/. The
misterhouse debian package can be found at
http://www.running
Andreas Bombe <[EMAIL PROTECTED]> writes:
> It's just that making the package non-native makes it easier to
> handle unless it's really a native package (i.e. written
> specifically for Debian).
YMMV, obviously. I find it easier to maintain quintuple-agent without
Debian subversions; "native" if
Some weeks ago I received Bug#96254 on one of my package: ocaml-xstr,
the problem is a build failure on a m68k machine. The reason is that a
package needed in ocaml-xstr compilation named ocaml-findlib, does not
work well on a m68k architecture.
I forwarded the problem to the upstream author and I
> I put it in contrib, since the licensing is a bit unclear. It probably
> belongs in main. The LGPL core do dynamically loading of GPL drivers -
> without explicit notice that that is allowed.
There's no license conflict there.
The GPL only allows linking with other code under the GPL, but the
On Tue, Jun 05, 2001 at 07:51:08PM +0200, Stefano Zacchiroli wrote:
> Some weeks ago I received Bug#96254 on one of my package: ocaml-xstr,
> the problem is a build failure on a m68k machine. The reason is that a
> package needed in ocaml-xstr compilation named ocaml-findlib, does not
> work well o
* Stefano Zacchiroli
| How can I solve the problem? May I ask for help on debian-devel or on
| debian-m68k ML?
That is one of the ways of doing it, yes. m68k would probably be best.
| Cause the problem is related to another package, may I close the bug on
| ocaml-xstr and fill a new one agains
On 06/05/01 Michèl Alexandre Salim wrote:
> > Please LART upstream heavily and give the packages a
> > proper name. That
> > tradition has done it wrong is no reason to continue
> > doing it the
> > wrong way.
The version numbering used upstream is completely reasonable:
check the archives for th
On Tue, 5 Jun 2001, Stefano Zacchiroli wrote:
> Some weeks ago I received Bug#96254 on one of my package: ocaml-xstr,
> the problem is a build failure on a m68k machine. The reason is that a
> package needed in ocaml-xstr compilation named ocaml-findlib, does not
> work well on a m68k architecture
On Wed, Jun 06, 2001 at 02:04:33PM +0200, T.Pospisek's MailLists wrote:
> The quick and ugly way is of course to build a new debian package
> that excludes m68k from the supported architectures.
That's not very nice. ocaml-findlib is genuinely broken on m68k.
I verified it myself. However since I
On Wed, 6 Jun 2001, Hamish Moffatt wrote:
> On Wed, Jun 06, 2001 at 02:04:33PM +0200, T.Pospisek's MailLists wrote:
> > The quick and ugly way is of course to build a new debian package
> > that excludes m68k from the supported architectures.
>
> That's not very nice. ocaml-findlib is genuinely br
--- Robert Bihlmeyer <[EMAIL PROTECTED]> wrote:
>
> The line
> dh_shlibdeps -plibpango$(version)
> should generate either substvars or
> libpango0.substvars. If it does,
> dh_gencontrol is for some reason not picking that
> up. If it doesn't it
> is either broken, or libpango0 does not depe
--- Paolo Molaro <[EMAIL PROTECTED]> wrote:
> Note that probably all the gtk 1.3.x releases will
> be incompatible,
> so the package names should include also the micro
> number.
>
Makes sense, I'll do just that.
Thanks,
Michel
Do Y
Hi,
I'm going to sponsor a guy who has already completed a package which
seems to be in good shape. It is my first sponsorship, and I'd like to
upload his package. Now the questions:
- Should he register somewhere as a sponsored guy? (some time ago,
when I was sponsored before entering Debian, I
On Wed, Jun 06, 2001 at 05:48:46PM +0200, Jesus M. Gonzalez-Barahona wrote:
> I'm going to sponsor a guy who has already completed a package which
> seems to be in good shape. It is my first sponsorship, and I'd like to
> upload his package. Now the questions:
>
> - Should he register somewhere a
On Wed, 6 Jun 2001, Paolo Molaro wrote:
> On 06/05/01 Michèl Alexandre Salim wrote:
> > > Please LART upstream heavily and give the packages a
> > > proper name. That
> > > tradition has done it wrong is no reason to continue
> > > doing it the
> > > wrong way.
> The version numbering used upstr
On Thu, May 31, 2001 at 10:31:03AM +0100, Jon Middleton wrote:
>[ I'm CC'ing debian-perl in-case the Perl Maintainer's have any views, I
>guess any other discussion should happen there ]
>
>OK, I'll file a bug against ftp.debian.org acessing for libfile-temp-perl's
>removal after perl-modules 5.6.1
Hi!
May I have missed something and in unstable /usr/lib/X11/app-defaults
moved to /etc/X11/app-defaults? My package actually doesn't use
app-defaults. I noticed this when I compiled a package from unstable on
my stable box and got error messages on a missing file in app-defaults.
Christoph
--
On Thu, 7 Jun 2001, Christoph Baumann wrote:
> [..] have [..] /usr/lib/X11/app-defaults [..] moved to
> /etc/X11/app-defaults?
yes.
*t
Tomas Pospisek
SourcePole - Linux & Open Source Solutio
On Tue, Jun 05, 2001 at 04:01:20AM +0100, Mich?l Alexandre Salim wrote:
> Rather a neat idea. And certainly I have seen it
> implemented - for Enlightenment 0.17 CVS for instance.
> It is still the duty of the Debian maintainer to make
> sure the Debian version of the scripts conform to
> Debian sp
Christoph Baumann <[EMAIL PROTECTED]> wrote:
>May I have missed something and in unstable /usr/lib/X11/app-defaults
>moved to /etc/X11/app-defaults? My package actually doesn't use
>app-defaults. I noticed this when I compiled a package from unstable on
>my stable box and got error messages on a mi
Christoph Baumann <[EMAIL PROTECTED]> wrote:
>May I have missed something and in unstable /usr/lib/X11/app-defaults
>moved to /etc/X11/app-defaults? My package actually doesn't use
>app-defaults. I noticed this when I compiled a package from unstable on
>my stable box and got error messages on a m
On Tue, Jun 05, 2001 at 04:01:20AM +0100, Mich?l Alexandre Salim wrote:
> Rather a neat idea. And certainly I have seen it
> implemented - for Enlightenment 0.17 CVS for instance.
> It is still the duty of the Debian maintainer to make
> sure the Debian version of the scripts conform to
> Debian s
On Thu, 7 Jun 2001, Christoph Baumann wrote:
> [..] have [..] /usr/lib/X11/app-defaults [..] moved to
> /etc/X11/app-defaults?
yes.
*t
Tomas Pospisek
SourcePole - Linux & Open Source Soluti
Hi!
May I have missed something and in unstable /usr/lib/X11/app-defaults
moved to /etc/X11/app-defaults? My package actually doesn't use
app-defaults. I noticed this when I compiled a package from unstable on
my stable box and got error messages on a missing file in app-defaults.
Christoph
--
48 matches
Mail list logo
