On Sun, Jun 08, 2003 at 09:01:07PM -0400, Matt Zimmerman wrote:
>
>If the files need
> certain ownership on the installed system, set the permissions in postinst
> (allowing for the user to dpkg-statoverride them if they want).
>
Ass
On Sun, Jun 08, 2003 at 08:51:00PM +0200, Marc Haber wrote:
> I am currently preparing packages for rrfw (see bug#186828). The
> daemons that come with rrfw run as user rrfw, and the Makefiles of
> that package insist on chowning some files to rrfw at build time. That
> - of course - fails when th
Marc Haber wrote:
> I am currently preparing packages for rrfw (see bug#186828). The
> daemons that come with rrfw run as user rrfw, and the Makefiles of
> that package insist on chowning some files to rrfw at build time. That
> - of course - fails when the rrfw account does not exist at build
> ti
On Sun, Jun 08, 2003 at 08:51:00PM +0200, Marc Haber wrote:
> I am currently preparing packages for rrfw (see bug#186828). The
> daemons that come with rrfw run as user rrfw, and the Makefiles of
> that package insist on chowning some files to rrfw at build time. That
> - of course - fails when th
Marc Haber wrote:
> I am currently preparing packages for rrfw (see bug#186828). The
> daemons that come with rrfw run as user rrfw, and the Makefiles of
> that package insist on chowning some files to rrfw at build time. That
> - of course - fails when the rrfw account does not exist at build
> ti
On Sunday 08 June 2003 11:51, Marc Haber wrote:
> Hi,
>
> I am currently preparing packages for rrfw (see bug#186828). The
> daemons that come with rrfw run as user rrfw, and the Makefiles of
> that package insist on chowning some files to rrfw at build time. That
> - of course - fails when the rrf
On Sunday 08 June 2003 11:51, Marc Haber wrote:
> Hi,
>
> I am currently preparing packages for rrfw (see bug#186828). The
> daemons that come with rrfw run as user rrfw, and the Makefiles of
> that package insist on chowning some files to rrfw at build time. That
> - of course - fails when the rrf
Hi Luca, debian-mentors.
I'd like to ask for advice on the following:
Luca has RFA'd phpgroupware quite a while ago. It also has a number of bug
reports of "elevated severities" (above normal), for most of which there seem to
be patches.
I would like to either NMU or, better yet, find some more pe
Marc Haber wrote:
> How am I supposed to handle this? Shall I change the build mechanisms
> so that the account is not needed at build time, shall I pester
> upstream to have that changed, or is there a workaround available?
IMHO the best solution would be involving the upstream. (This is, of cours
Hi,
I am currently preparing packages for rrfw (see bug#186828). The
daemons that come with rrfw run as user rrfw, and the Makefiles of
that package insist on chowning some files to rrfw at build time. That
- of course - fails when the rrfw account does not exist at build
time.
How am I supposed
Hi Luca, debian-mentors.
I'd like to ask for advice on the following:
Luca has RFA'd phpgroupware quite a while ago. It also has a number of bug
reports of "elevated severities" (above normal), for most of which there seem to
be patches.
I would like to either NMU or, better yet, find some more pe
Marc Haber wrote:
> How am I supposed to handle this? Shall I change the build mechanisms
> so that the account is not needed at build time, shall I pester
> upstream to have that changed, or is there a workaround available?
IMHO the best solution would be involving the upstream. (This is, of cours
Hi,
I am currently preparing packages for rrfw (see bug#186828). The
daemons that come with rrfw run as user rrfw, and the Makefiles of
that package insist on chowning some files to rrfw at build time. That
- of course - fails when the rrfw account does not exist at build
time.
How am I supposed
On Sun, Jun 08, 2003 at 10:22:51PM +0900, Junichi Uekawa wrote:
>
> > > The normal procedure is to rename the binary package to
> > > libgtop2-1 (it should probably have been libgtop2.0-1, but
> > > people seem to have their own tastes about this.)
> >
> > Ok, thanks for the info, and what is t
> > The normal procedure is to rename the binary package to
> > libgtop2-1 (it should probably have been libgtop2.0-1, but
> > people seem to have their own tastes about this.)
>
> Ok, thanks for the info, and what is the procedure concerning this and
> NMUs ? Also, while this name change mean
On Sun, Jun 08, 2003 at 10:22:51PM +0900, Junichi Uekawa wrote:
>
> > > The normal procedure is to rename the binary package to
> > > libgtop2-1 (it should probably have been libgtop2.0-1, but
> > > people seem to have their own tastes about this.)
> >
> > Ok, thanks for the info, and what is t
> > The normal procedure is to rename the binary package to
> > libgtop2-1 (it should probably have been libgtop2.0-1, but
> > people seem to have their own tastes about this.)
>
> Ok, thanks for the info, and what is the procedure concerning this and
> NMUs ? Also, while this name change mean
RMagick is a Ruby API for ImageMagick (along the lines of PerlMagick).
See http://home.nc.rr.com/rmagick/ for more details.
I've ITP'ed RMagick (Bug#195080), and produced some *.debs, which are
available at
http://www.dogbiscuit.org/mdub/software/debian/unstable/
I'm seeking a Debian developer
Amaya dijo:
> I will (if no one else has offered to sponsor you by now).
Done!
--
I would rather starve than lose your acceptance
.''`.My eyes will always show my empty soul
: :' :- Boy Sets Fire
`. `' Proudly running Debian GNU/Linux (Sid 2.4.2
Juan Manuel García Molina dijo:
> This upload will fix an RC bug. Al this moment, there is a patch
> correcting this bug in DBTS, but i would prefer an upload of the
> package.
I will (if no one else has offered to sponsor you by now).
--
I would rather starve than lose your acceptance
RMagick is a Ruby API for ImageMagick (along the lines of PerlMagick).
See http://home.nc.rr.com/rmagick/ for more details.
I've ITP'ed RMagick (Bug#195080), and produced some *.debs, which are
available at
http://www.dogbiscuit.org/mdub/software/debian/unstable/
I'm seeking a Debian developer
On Sun, Jun 08, 2003 at 06:35:02PM +0900, Junichi Uekawa wrote:
>
> > I am currently preparing a NMU for libgtop2, which is broken and whose
> > maintainer told me has no time to fix right now.
> >
> > Now, the problem was that the libgtop library moved from 0.so.0.0.1 to
> > 0.so.1.0.1, and the
Amaya dijo:
> I will (if no one else has offered to sponsor you by now).
Done!
--
I would rather starve than lose your acceptance
.''`.My eyes will always show my empty soul
: :' :- Boy Sets Fire
`. `' Proudly running Debian GNU/Linux (Sid 2.4.2
> I am currently preparing a NMU for libgtop2, which is broken and whose
> maintainer told me has no time to fix right now.
>
> Now, the problem was that the libgtop library moved from 0.so.0.0.1 to
> 0.so.1.0.1, and the install rules didn't catch this changes.
The normal procedure is to rename
On Sun, Jun 08, 2003 at 08:53:47AM +0200, Sven Luther wrote:
> Hello,
>
Hello,
>
> (Currently reading the Policy document, but it doesn't say much about
> this, is there another reference document speaking about shared lib
> soname ?)
>
Quoting the developer-reference:
Good prac
Juan Manuel García Molina dijo:
> This upload will fix an RC bug. Al this moment, there is a patch
> correcting this bug in DBTS, but i would prefer an upload of the
> package.
I will (if no one else has offered to sponsor you by now).
--
I would rather starve than lose your acceptance
On Sun, Jun 08, 2003 at 10:10:33AM +0200, Andreas Metzler wrote:
> On Sun, Jun 08, 2003 at 08:53:47AM +0200, Sven Luther wrote:
> > I am currently preparing a NMU for libgtop2, which is broken and whose
> > maintainer told me has no time to fix right now.
>
> > Now, the problem was that the libgt
On Sun, Jun 08, 2003 at 08:53:47AM +0200, Sven Luther wrote:
> I am currently preparing a NMU for libgtop2, which is broken and whose
> maintainer told me has no time to fix right now.
> Now, the problem was that the libgtop library moved from 0.so.0.0.1 to
> 0.so.1.0.1, and the install rules did
On Sun, Jun 08, 2003 at 06:35:02PM +0900, Junichi Uekawa wrote:
>
> > I am currently preparing a NMU for libgtop2, which is broken and whose
> > maintainer told me has no time to fix right now.
> >
> > Now, the problem was that the libgtop library moved from 0.so.0.0.1 to
> > 0.so.1.0.1, and the
> I am currently preparing a NMU for libgtop2, which is broken and whose
> maintainer told me has no time to fix right now.
>
> Now, the problem was that the libgtop library moved from 0.so.0.0.1 to
> 0.so.1.0.1, and the install rules didn't catch this changes.
The normal procedure is to rename
On Sun, Jun 08, 2003 at 08:53:47AM +0200, Sven Luther wrote:
> Hello,
>
Hello,
>
> (Currently reading the Policy document, but it doesn't say much about
> this, is there another reference document speaking about shared lib
> soname ?)
>
Quoting the developer-reference:
Good prac
Hello,
I am currently preparing a NMU for libgtop2, which is broken and whose
maintainer told me has no time to fix right now.
Now, the problem was that the libgtop library moved from 0.so.0.0.1 to
0.so.1.0.1, and the install rules didn't catch this changes.
Now, if i understood this change righ
On Sun, Jun 08, 2003 at 10:10:33AM +0200, Andreas Metzler wrote:
> On Sun, Jun 08, 2003 at 08:53:47AM +0200, Sven Luther wrote:
> > I am currently preparing a NMU for libgtop2, which is broken and whose
> > maintainer told me has no time to fix right now.
>
> > Now, the problem was that the libgt
On Sun, Jun 08, 2003 at 08:53:47AM +0200, Sven Luther wrote:
> I am currently preparing a NMU for libgtop2, which is broken and whose
> maintainer told me has no time to fix right now.
> Now, the problem was that the libgtop library moved from 0.so.0.0.1 to
> 0.so.1.0.1, and the install rules did
Hello,
I am currently preparing a NMU for libgtop2, which is broken and whose
maintainer told me has no time to fix right now.
Now, the problem was that the libgtop library moved from 0.so.0.0.1 to
0.so.1.0.1, and the install rules didn't catch this changes.
Now, if i understood this change righ
35 matches
Mail list logo
