Re: Modifying a file from another package (rather than replacing it)

[Francesco P. Lovergine]

On Sun, Dec 26, 2010 at 02:10:08PM +0100, Malte Forkel wrote:
> But, aside from the pbuilder specifics: Is there any policy, best
> practice, or LSB scheme for extending an existing package? Are there any
> hooks to re-apply changes to an existing package after it has been updated?
> 

It definitively depends on the specific packageis. When ever it happened to
me, I followed up all the maintainer(s) involved and we found all together
a way to have a working pool of packages. 

-- 
Francesco P. Lovergine


-- 
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/20101227085648.ga2...@mithrandir

Bug#608104: ITP: dockbarx -- A task bar and launcher dock with grouping and group manipulation

[Klaus Reimer]

Package: wnpp
Severity: wishlist
Owner: Klaus Reimer 


* Package name: dockbarx
  Version : 0.42
  Upstream Author : Matias Särs 

* URL : 
http://gnome-look.org/content/show.php/DockbarX?content=101604
* License : GPLv3
  Programming Lang: Python
  Description : A task bar and launcher dock with grouping and group 
manipulation

This gnome applet provides a task bar which also works as a dock for
starting applications. It supports grouping, group manipulation and
window previews.



--
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/20101227084919.20604.99466.report...@marvin.ailis.de

Bug#608105: ITP: libformconv -- math formula converter library

[Giovanni Mascellani]

Package: wnpp
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org

   Package name: libformconv
Version: 0.9.0
Upstream Author: Zoltán Kovács  and others
URL: http://formconv.sourceforge.net/
License: LGPL
Description: math formula converter library
Formconv is a general conversion library and tool between different
formats for math formulae. It currently supports intuitive (a simplified
Pascal-like syntax), MathML and LISP as input formats and lots of
different output formats (among the others: LaTeX, HTML, MuPAD,
Mathematica, Maple, Maxima, gnuplot, Java, C, MathML and LISP).

Formconv is mainly used in mathematics web applications to check the
input syntactically and convert it to various formats in order to work
on it by  other  programs: CAS or other mathematics tools. Although many
CAS are able to export formulas in various formats, formconv is known to
be faster and smaller as a general tool.  However, there are no official
statistics or benchmarking tests yet to show scientifically reliable
differences of efficiency of the export facility of the mathematical
systems and formconv.

This package is a dependendy of rtzme (bug #599623).

Ciao, Giovanni.
-- 
Giovanni Mascellani 
Pisa, Italy

Web: http://poisson.phc.unipi.it/~mascellani
Jabber: g.mascell...@jabber.org / giova...@elabor.homelinux.org



signature.asc
Description: OpenPGP digital signature

Re: Bug#608098: gnome-core: revert mass migration from -desktop-environment to -core

[Martin-Éric Racine]

On Mon, Dec 27, 2010 at 11:22 AM, Josselin Mouette  wrote:
> retitle 608098 RFP: gnome-martin-eric-racine - metapackage for Martin-Éric 
> Racine’s needs
> reassign 608098 wnpp
> kthxbye
>
> Le lundi 27 décembre 2010 à 08:07 +0200, Martin-Éric Racine a écrit :
>> The massive migration of dependencies from gnome-desktop-environment
>> to gnome-core is extremely undesirable, because it spoils the
>> usefulness that gnome-core used to have in pulling just enough
>> packages to have a basic GNOME environment. Now, instead, it pulls WAY
>> too many packages and leaves the user without any simple method for
>> installing basic GNOME components.
>
> The gnome-core package is not here to fulfill the needs of a given
> user.
>
> If you need a specific set of packages, please make your metapackages
> yourself. See brdesktop-gnome for an example of such a recurrent
> failure.

Sorry, but am I the only one who considers this reply as pointlessly
abrasive, inappropriate and offensive?

Regards,
Martin-Éric


--
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/aanlktimwkng1q_3hdbswbmwf+sm+hurrdce9snjjw...@mail.gmail.com

using perl in preinst script

[Rahul Amaram]

Hi,
I am the maintainer for calendarserver. I have a query reg. preinst
script. I need to perform some action during preinst before the upgrade of
calendarserver happens from 1.x to 2.x. For this, I wrote the necessary
code in python in preinst script. But this was rejected into being accepted
into squeeze as writing python code or calling the python interpreter in
preinst is not permitted.

As the upgrade code has to parse .plist files, writing shell script would
be a very difficult task. So I would like to know what are my other
options? Could I write it in perl?

Also is there any estimate date on the release of squeeze?

Looking forward to a response.

Thanks and Regards,
Rahul.


--
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/a7a5496e2a2b09800fc6f6bc3a152...@localhost

Re: using perl in preinst script

[Neil Williams]

On Mon, 27 Dec 2010 16:53:11 +0530
Rahul Amaram  wrote:

> As the upgrade code has to parse .plist files, writing shell script
> would be a very difficult task. So I would like to know what are my
> other options? Could I write it in perl?

$ file /var/lib/dpkg/info/*.preinst|grep -v "shell script text"

Yes preinst scripts can be in perl - the other alternative is a
compiled executable but that is only really an option if the package
itself is already Arch:any. So, your packge is left with perl if shell
isn't practical.

I don't know the package but sometimes it is only necessary to identify
that the upgrade needs to be run in the preinst and then actually
handle the workload in the postinst (when you could use python), maybe
via a dpkg trigger. What portion of the *results* of the parsing is
actually required for the configuration of calendarserver itself? It is
worth investigating whether a preinst is actually required or whether
the work can be postponed.

> Also is there any estimate date on the release of squeeze?

When the RC bugs are fixed. 

It seems unlikely that this particular package would affect the
release as the new version won't migrate into testing now anyway - the
broken preinst / Pre-Depends-not-discussed-previously-on-devel issue
only exists in unstable and that can be fixed without affecting the
release of Squeeze. (It does need to be fixed though.)

-- 


Neil Williams
=
http://www.linux.codehelp.co.uk/



pgpNhbCWqbQpm.pgp
Description: PGP signature

Bug#608113: ITP: python-dbf -- Python module for reading and writing dbf files

[Margarita Manterola]

Package: wnpp
Severity: wishlist
Owner: Margarita Manterola 

* Package name: python-dbf
  Version : 0.88.16
  Upstream Author : Ethan Furman 
* URL : http://groups.google.com/group/python-dbase
* License : BSD License
  Programming Lang: Python
  Description : Python module for reading and writing dbf files

A pure python package for reading and writing dBase III, FoxPro, and Visual
FoxPro 6 .dbf files (including memos).
Text is returned as unicode, and codepage settings in tables are honored.
.
Currently not supported: index files, null fields, auto-incrementing fields.



-- 
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/20101227115019.27458.37570.report...@ulises.gnuservers.com.ar

Re: using perl in preinst script

[Tollef Fog Heen]

]] Rahul Amaram 


| I am the maintainer for calendarserver. I have a query reg. preinst
| script. I need to perform some action during preinst before the upgrade of
| calendarserver happens from 1.x to 2.x. For this, I wrote the necessary
| code in python in preinst script. But this was rejected into being accepted
| into squeeze as writing python code or calling the python interpreter in
| preinst is not permitted.

As long as you have the necessary Pre-Depends, that should be fine, I'd
imagine.  (You have to discuss adding the pre-depends on debian-devel,
but as long as you have a good reason to, I don't see a problem with
that.)

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are


--
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/878vzbbe6q@qurzaw.varnish-software.com

Re: using perl in preinst script

[Adam Borowski]

On Mon, Dec 27, 2010 at 04:53:11PM +0530, Rahul Amaram wrote:
> Hi,
> I am the maintainer for calendarserver. I have a query reg. preinst
> script. I need to perform some action during preinst before the upgrade of
> calendarserver happens from 1.x to 2.x. For this, I wrote the necessary
> code in python in preinst script. But this was rejected into being accepted
> into squeeze as writing python code or calling the python interpreter in
> preinst is not permitted.

Yeah, you can count on dependencies being installed in postinst but not
preinst (nor postrm purge).  One solution would be to move your script to
postinst if that's possible.  Another would be to add a Pre-Dependency,
although they are frowned upon unless there's no better way.  If your script
is relatively simple, I'd go with perl as you said.

> As the upgrade code has to parse .plist files, writing shell script would
> be a very difficult task. So I would like to know what are my other
> options? Could I write it in perl?

Sure, as long as you don't use any modules not present in "perl-base".


cheers.
-- 
1KB // Microsoft corollary to Hanlon's razor:
//  Never attribute to stupidity what can be
//  adequately explained by malice.


-- 
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/20101227120218.ga20...@angband.pl

Re: using perl in preinst script

[Neil Williams]

On Mon, 27 Dec 2010 13:19:57 +0100
Tollef Fog Heen  wrote:

> ]] Rahul Amaram 
> 
> 
> | I am the maintainer for calendarserver. I have a query reg. preinst
> | script. I need to perform some action during preinst before the
> | upgrade of calendarserver happens from 1.x to 2.x. For this, I
> | wrote the necessary code in python in preinst script. But this was
> | rejected into being accepted into squeeze as writing python code or
> | calling the python interpreter in preinst is not permitted.
> 
> As long as you have the necessary Pre-Depends, that should be fine,
> I'd imagine.  (You have to discuss adding the pre-depends on
> debian-devel, but as long as you have a good reason to, I don't see a
> problem with that.)

See #608099 for rejection of the python preinst - as python is not
essential, a Pre-Depends on python isn't workable. Good reason or no,
there is a problem with a python preinst. Perl is a suitable
alternative.

-- 


Neil Williams
=
http://www.linux.codehelp.co.uk/



pgpig07FLbeYj.pgp
Description: PGP signature

Re: using perl in preinst script

[Rahul Amaram]

Hi,
Thanks a lot for the prompt responses. I am a new maintainer (sponsored)
and so not aware of some issues. I really appreciate all the help given in
the list.

Continuing with my previous mail, this is what the preinst script does:

- Read the current caldavd.plist configuration file if it exists
- If NSS directory service is configured in caldavd.plist, perform some
action on caldavd data directories for those NSS users and groups

And this has to be done before the upgraded calendarserver runs for the
first time. Hence running it in postinst is not an option.

As I can see, my only option seems to be using perl-base. But that still
leaves me with a difficulty because to use the Plist parser module I will
have to include many other modules. Not sure how to handle this. This is
something I'll have to figure out.

Anyway, keeping that apart, is there any chance that the upgraded
calendarserver could be pushed into squeeze if I make those changes now?
The reason being I am extremely occupied with other tasks and if this
package cannot be pushed into squeeze I'd rather work on it after a while.

Thanks,
Rahul.


On Mon, 27 Dec 2010 12:45:26 +, Neil Williams 
wrote:
> On Mon, 27 Dec 2010 13:19:57 +0100
> Tollef Fog Heen  wrote:
> 
>> ]] Rahul Amaram 
>> 
>> 
>> | I am the maintainer for calendarserver. I have a query reg. preinst
>> | script. I need to perform some action during preinst before the
>> | upgrade of calendarserver happens from 1.x to 2.x. For this, I
>> | wrote the necessary code in python in preinst script. But this was
>> | rejected into being accepted into squeeze as writing python code or
>> | calling the python interpreter in preinst is not permitted.
>> 
>> As long as you have the necessary Pre-Depends, that should be fine,
>> I'd imagine.  (You have to discuss adding the pre-depends on
>> debian-devel, but as long as you have a good reason to, I don't see a
>> problem with that.)
> 
> See #608099 for rejection of the python preinst - as python is not
> essential, a Pre-Depends on python isn't workable. Good reason or no,
> there is a problem with a python preinst. Perl is a suitable
> alternative.


--
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/8449e9fb844716f6cbbdd39b27f57...@localhost

Re: using perl in preinst script

[Neil Williams]

On Mon, 27 Dec 2010 18:27:10 +0530
Rahul Amaram  wrote:

> - Read the current caldavd.plist configuration file if it exists
> - If NSS directory service is configured in caldavd.plist,

... then stop processing in the preinst at this point and set the config
to not use NSS until configured.

> perform
> some action on caldavd data directories for those NSS users and groups

... so do this in postinst then restart with the updated config.
 
> And this has to be done before the upgraded calendarserver runs for
> the first time. 

Stop the server in the preinst (if not already stopped in the prerm of
the old version) and don't start it until the postinst has finished
doing the changes. Don't expect the server to be running between
running the preinst and the postinst. Servers should be stopped before
unpacking and restarted afterwards, in the postinst and after any
config changes have been implemented.

> Hence running it in postinst is not an option.

Actually, it probably is the only option.

If necessary, consider changing the server so that it can run without
needing this change. More commonly, ensure it is stopped in preinst
and not started until after the postinst has finished.
 
> Anyway, keeping that apart, is there any chance that the upgraded
> calendarserver could be pushed into squeeze if I make those changes
> now?

No. Squeeze is already in deep freeze. Only RC bug fixes are going to be
accepted. It is too late to get non-RC bug fixes into Squeeze and the
version in testing is not RC buggy (the version in unstable is
potentially RC buggy). You'll just have to fix it in unstable and
backport later.

> The reason being I am extremely occupied with other tasks

It's too late - Debian releases take long enough as it is without
waiting for everyone to have free time for their pet fixes to get in.

> and if
> this package cannot be pushed into squeeze I'd rather work on it
> after a while.

You'll need to work on the package in unstable sooner rather than
later. The version is unstable is buggy. Sooner or later you'll end up
with a bug report that the preinst failed because python is not
guaranteed to be configured when the preinst starts and that bug
report would probably be RC.

If you can't work on that now, pull the python preinst change out of
the version in unstable and leave NSS configuration to the admin. Put
something into README.Debian or News.

Whatever you decide, the version in unstable does need to be fixed. You
cannot expect a python preinst to actually work.

-- 


Neil Williams
=
http://www.linux.codehelp.co.uk/



pgpX8NH7udDi9.pgp
Description: PGP signature

Re: using perl in preinst script

[Luk Claes]

On 12/27/2010 01:45 PM, Neil Williams wrote:
> On Mon, 27 Dec 2010 13:19:57 +0100
> Tollef Fog Heen  wrote:
> 
>> ]] Rahul Amaram 
>>
>>
>> | I am the maintainer for calendarserver. I have a query reg. preinst
>> | script. I need to perform some action during preinst before the
>> | upgrade of calendarserver happens from 1.x to 2.x. For this, I
>> | wrote the necessary code in python in preinst script. But this was
>> | rejected into being accepted into squeeze as writing python code or
>> | calling the python interpreter in preinst is not permitted.
>>
>> As long as you have the necessary Pre-Depends, that should be fine,
>> I'd imagine.  (You have to discuss adding the pre-depends on
>> debian-devel, but as long as you have a good reason to, I don't see a
>> problem with that.)
> 
> See #608099 for rejection of the python preinst - as python is not
> essential, a Pre-Depends on python isn't workable. Good reason or no,
> there is a problem with a python preinst. Perl is a suitable
> alternative.

I thought there were some plans to try to get rid of perl-base being
essential, in that case only shell (or C?) is a real alternative. Though
in most cases including this one there is no real need to have the
service running during the upgrade and you can easily do python or perl
in the postinst.

Cheers

Luk


-- 
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/4d18a65c.5040...@debian.org

Re: using perl in preinst script

[Rahul Amaram]

Hi Neil,
Thanks for the response. I didn't intend to work on this update as per 
my leisure. I greatly admire the Debian release team for the effort they 
put in, in trying to make Debian a great experience to the end users. As 
I've already told you, I am new and therefore didn't know of the 
deep-freeze of Squeeze. Or else I would have definitely worked on it 
earlier itself.


Anyway, coming back to the solution. This is what I plan to do. Kindly 
provide any necessary feedback.


1. Stop the server in preinst and if necessary copy the current 
configuration file to a temporary location.
2. In postinst, write python code to check if NSS directory service is 
being used (by parsing the configuration file) and if so take the 
appropriate action. Once this is done, delete the temporary copy of 
configuration file.


Also I believe for this, python needn't be added to Pre-Depends but only 
to Depends.


Pushing this script would make upgrade of calendarserver data 
directories seamless to end users who use NSS directory backend. This is 
the reason why I am so keen on pushing in this change so that the 
upgrade will cause the least inconvenience to end users.


If the above solution is acceptable, then I will work on it right away. 
If not, then I'll consider removing python from the preinst script 
altogether as rewriting it in perl/shell is a really huge task for me.


Cheers,
Rahul.

On Monday 27 December 2010 07:12 PM, Neil Williams wrote:

On Mon, 27 Dec 2010 18:27:10 +0530
Rahul Amaram  wrote:

   

- Read the current caldavd.plist configuration file if it exists
- If NSS directory service is configured in caldavd.plist,
 

... then stop processing in the preinst at this point and set the config
to not use NSS until configured.

   

perform
some action on caldavd data directories for those NSS users and groups
 

... so do this in postinst then restart with the updated config.

   

And this has to be done before the upgraded calendarserver runs for
the first time.
 

Stop the server in the preinst (if not already stopped in the prerm of
the old version) and don't start it until the postinst has finished
doing the changes. Don't expect the server to be running between
running the preinst and the postinst. Servers should be stopped before
unpacking and restarted afterwards, in the postinst and after any
config changes have been implemented.

   

Hence running it in postinst is not an option.
 

Actually, it probably is the only option.

If necessary, consider changing the server so that it can run without
needing this change. More commonly, ensure it is stopped in preinst
and not started until after the postinst has finished.

   

Anyway, keeping that apart, is there any chance that the upgraded
calendarserver could be pushed into squeeze if I make those changes
now?
 

No. Squeeze is already in deep freeze. Only RC bug fixes are going to be
accepted. It is too late to get non-RC bug fixes into Squeeze and the
version in testing is not RC buggy (the version in unstable is
potentially RC buggy). You'll just have to fix it in unstable and
backport later.

   

The reason being I am extremely occupied with other tasks
 

It's too late - Debian releases take long enough as it is without
waiting for everyone to have free time for their pet fixes to get in.

   

and if
this package cannot be pushed into squeeze I'd rather work on it
after a while.
 

You'll need to work on the package in unstable sooner rather than
later. The version is unstable is buggy. Sooner or later you'll end up
with a bug report that the preinst failed because python is not
guaranteed to be configured when the preinst starts and that bug
report would probably be RC.

If you can't work on that now, pull the python preinst change out of
the version in unstable and leave NSS configuration to the admin. Put
something into README.Debian or News.

Whatever you decide, the version in unstable does need to be fixed. You
cannot expect a python preinst to actually work.

   



--
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/4d18bfa0.2040...@users.sourceforge.net

Re: using perl in preinst script

[Philipp Kern]

On 2010-12-27, Rahul Amaram  wrote:
> Thanks for the response. I didn't intend to work on this update as per 
> my leisure. I greatly admire the Debian release team for the effort they 
> put in, in trying to make Debian a great experience to the end users. As 
> I've already told you, I am new and therefore didn't know of the 
> deep-freeze of Squeeze. Or else I would have definitely worked on it 
> earlier itself.

I'd advise you to read the mailing list debian-devel-announce, which is
mandatory to read for all Debian Developers and should thus also be
read by contributors.  That's also the place where such status changes /:x
updates are published.

Kind regards
Philipp Kern


-- 
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/slrnihhge8.65i.tr...@kelgar.0x539.de

Re: using perl in preinst script

[Aron Xu]

On Tue, Dec 28, 2010 at 00:32, Rahul Amaram
 wrote:
> Hi Neil,
> Thanks for the response. I didn't intend to work on this update as per my
> leisure. I greatly admire the Debian release team for the effort they put
> in, in trying to make Debian a great experience to the end users. As I've
> already told you, I am new and therefore didn't know of the deep-freeze of
> Squeeze. Or else I would have definitely worked on it earlier itself.
>
> Anyway, coming back to the solution. This is what I plan to do. Kindly
> provide any necessary feedback.
>
> 1. Stop the server in preinst and if necessary copy the current
> configuration file to a temporary location.
> 2. In postinst, write python code to check if NSS directory service is being
> used (by parsing the configuration file) and if so take the appropriate
> action. Once this is done, delete the temporary copy of configuration file.
>
> Also I believe for this, python needn't be added to Pre-Depends but only to
> Depends.
>

I still think adding python to Depends only because a maintainer
script needs it is costing too much, if the application itself doesn't
need python at all.

-- 
Regards,
Aron Xu


-- 
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/aanlktinvco8vf+ns3k1+6kbxgz2corze9arx4_ojc...@mail.gmail.com

Re: using perl in preinst script

[Russ Allbery]

Luk Claes  writes:

> I thought there were some plans to try to get rid of perl-base being
> essential, in that case only shell (or C?) is a real alternative.

I cannot imagine this ever happening at a practical level.

-- 
Russ Allbery (r...@debian.org)   


-- 
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/8739pj2mar@windlord.stanford.edu

Re: using perl in preinst script

[Rahul Amaram]

Thanks Philips. I've subscribed to the debian-devel-announce list. Is it 
also necessary that I subscribe to debian-announce i.e. will posts to 
debian-announce be automatically marked to debian-devel-annouce?



On Monday 27 December 2010 10:11 PM, Philipp Kern wrote:

On 2010-12-27, Rahul Amaram  wrote:
   

Thanks for the response. I didn't intend to work on this update as per
my leisure. I greatly admire the Debian release team for the effort they
put in, in trying to make Debian a great experience to the end users. As
I've already told you, I am new and therefore didn't know of the
deep-freeze of Squeeze. Or else I would have definitely worked on it
earlier itself.
 

I'd advise you to read the mailing list debian-devel-announce, which is
mandatory to read for all Debian Developers and should thus also be
read by contributors.  That's also the place where such status changes /:x
updates are published.

Kind regards
Philipp Kern


   



--
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/4d18c94d.8090...@users.sourceforge.net

Re: using perl in preinst script

[Rahul Amaram]

The package depends on python anyways. My only query is as I am using 
python in postinst script, is it sufficient to mention it as part of 
Depends or should it still be mentioned in Pre-Depends?


Apart from that, as per the response given by Neil and also my 
sponsorer, I think the below logic should do fine for the upgrade script.


Thanks,
Rahul.

On Monday 27 December 2010 10:16 PM, Aron Xu wrote:

On Tue, Dec 28, 2010 at 00:32, Rahul Amaram
  wrote:
   

Hi Neil,
Thanks for the response. I didn't intend to work on this update as per my
leisure. I greatly admire the Debian release team for the effort they put
in, in trying to make Debian a great experience to the end users. As I've
already told you, I am new and therefore didn't know of the deep-freeze of
Squeeze. Or else I would have definitely worked on it earlier itself.

Anyway, coming back to the solution. This is what I plan to do. Kindly
provide any necessary feedback.

1. Stop the server in preinst and if necessary copy the current
configuration file to a temporary location.
2. In postinst, write python code to check if NSS directory service is being
used (by parsing the configuration file) and if so take the appropriate
action. Once this is done, delete the temporary copy of configuration file.

Also I believe for this, python needn't be added to Pre-Depends but only to
Depends.

 

I still think adding python to Depends only because a maintainer
script needs it is costing too much, if the application itself doesn't
need python at all.

   



--
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/4d18ca41.2010...@users.sourceforge.net

Re: using perl in preinst script

[Russ Allbery]

Rahul Amaram  writes:

> The package depends on python anyways. My only query is as I am using
> python in postinst script, is it sufficient to mention it as part of
> Depends or should it still be mentioned in Pre-Depends?

Depends is sufficient for postinst configure in the absence of circular
dependencies.  Other postinst actions have different restrictions and
expectations about what dependencies are satisfied.

-- 
Russ Allbery (r...@debian.org)   


-- 
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/87lj3b15bs@windlord.stanford.edu

Re: Full install/removal/upgrade test results available

[Mike Hommey]

On Wed, Dec 22, 2010 at 08:36:38PM +0100, Josselin Mouette wrote:
> Le mardi 21 décembre 2010 à 20:59 +0100, Mike Hommey a écrit : 
> > Adding update-python-modules -p in python-xpcom postinst could make
> > things slightly better, but that would still leave xulrunner-1.9.1's
> > postinst complaining if it's run before python-xpcom's.
> > 
> > What if xulrunner-1.9.1's postinst would do nothing for configure ?
> > would the trigger still kick in when one installs xulrunner-1.9.1 only?
> 
> You could use dpkg-trigger to force the trigger to be run after
> xulrunner-1.9.1 being installed.

Unfortunately, while some cases were fixed, the original case for which
the pre-depends was added fails again :(

(starting from xulrunner-1.9.1 already installed, and installing
python-xpcom, case which I forgot to test before my last uploads)
Unpacking python-xpcom (from
.../python-xpcom_1%3a0.0~hg20100212-3_amd64.deb) ...
Processing triggers for xulrunner-1.9.1 ...
Obtaining the module object from Python failed.

: No module named xpcom.server
Obtaining the module object from Python failed.

: No module named xpcom.server
Setting up libncursesw5 (5.7+20100313-4) ...
Setting up libssl0.9.8 (0.9.8o-4) ...
Setting up mime-support (3.51-1) ...
update-alternatives: using /usr/bin/see to provide /usr/bin/view (view)
in auto mode.
Setting up python2.6-minimal (2.6.6-8+b1) ...
Setting up python2.6 (2.6.6-8+b1) ...
Setting up python-minimal (2.6.6-3+squeeze4) ...
Setting up python (2.6.6-3+squeeze4) ...
Setting up python-support (1.0.11) ...
Setting up libpython2.6 (2.6.6-8+b1) ...
Setting up python-xpcom (1:0.0~hg20100212-3) ...
Processing triggers for python-support ...

Yes, the xulrunner-1.9.1 trigger happens right after unpack... before
python-xpcom's postinst g. I'm starting to hate dpkg triggers.

Mike


-- 
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/20101227175735.ga27...@glandium.org

Re: using perl in preinst script

[Philipp Kern]

On 2010-12-27, Rahul Amaram  wrote:
> Thanks Philips. I've subscribed to the debian-devel-announce list. Is it 
> also necessary that I subscribe to debian-announce i.e. will posts to 
> debian-announce be automatically marked to debian-devel-annouce?

No, debian-announce has press releases, which aren't as essential to the
developers.  But if you wonder about $release getting released, then you
should subscribe to it, too.  They aren't copied to d-d-a.

Kind regards
Philipp Kern


-- 
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/slrnihhnpp.6aq.tr...@kelgar.0x539.de

Re: Bug#608098: gnome-core: revert mass migration from -desktop-environment to -core

[Eugene V. Lyubimkin]

On 2010-12-27 11:31, Martin-Éric Racine wrote:
> On Mon, Dec 27, 2010 at 11:22 AM, Josselin Mouette  wrote:
> > retitle 608098 RFP: gnome-martin-eric-racine - metapackage for Martin-Éric 
> > Racine’s needs
[...]
> Sorry, but am I the only one who considers this reply as pointlessly
> abrasive, inappropriate and offensive?

I also don't like the style of the answer. Nevertheless, while I see
your rationale, I doubt it's enough to overrule the maintainer.

-- 
Eugene V. Lyubimkin aka JackYF, JID: jackyf.devel(maildog)gmail.com
C++/Perl developer, Debian Developer


-- 
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/20101227185457.ga17...@r500-debian

Re: Full install/removal/upgrade test results available

[Josselin Mouette]

Le lundi 27 décembre 2010 à 18:57 +0100, Mike Hommey a écrit : 
> On Wed, Dec 22, 2010 at 08:36:38PM +0100, Josselin Mouette wrote:
> > You could use dpkg-trigger to force the trigger to be run after
> > xulrunner-1.9.1 being installed.
> 
> Unfortunately, while some cases were fixed, the original case for which
> the pre-depends was added fails again :(

> Yes, the xulrunner-1.9.1 trigger happens right after unpack... before
> python-xpcom's postinst g. I'm starting to hate dpkg triggers.

Maybe you want dpkg-trigger --no-await ?

-- 
 .''`.  Josselin Mouette
: :' :
`. `'  “If you behave this way because you are blackmailed by someone,
  `-[…] I will see what I can do for you.”  -- Jörg Schilling


signature.asc
Description: This is a digitally signed message part

Re: Bug#608098: gnome-core: revert mass migration from -desktop-environment to -core

[Josselin Mouette]

Le lundi 27 décembre 2010 à 11:31 +0200, Martin-Éric Racine a écrit : 
> On Mon, Dec 27, 2010 at 11:22 AM, Josselin Mouette  wrote:
> > The gnome-core package is not here to fulfill the needs of a given
> > user.

> Sorry, but am I the only one who considers this reply as pointlessly
> abrasive, inappropriate and offensive?

I suggest that you spend the next days with bug reports from 50
different users, each of them having his own idea of what should be in
this or that metapackage.

Which reminds me of a recent debate on how to have more bug reports: on
this topic I really wish we had *less* bug reports overall, but more
useful ones.

Since you point this to a list that might be interested for a more
thorough picture, here it is: in squeeze, the gnome-session package now
depends on the basic components that are actually needed for running a
GNOME session. Since this change was made, I hadn’t known what to do of
gnome-core, as it had became obsolete. The size issue of fitting GNOME
on the first CD gave an obvious answer to what this metapackage should
become.

So in short: 
  * gnome-core = GNOME installation designed to fit on one CD 
  * gnome-desktop-environment ≈ GNOME as defined by upstream 
  * gnome = full GNOME installation for the default installation

If you are skilled enough to consider that the existing metapackages
don’t suit you and you need something lighter, you are also skilled
enough to install the needed packages by hand.

kthxbye,
-- 
 .''`.  Josselin Mouette
: :' :
`. `'  “If you behave this way because you are blackmailed by someone,
  `-[…] I will see what I can do for you.”  -- Jörg Schilling


signature.asc
Description: This is a digitally signed message part

Re: Full install/removal/upgrade test results available

[Mike Hommey]

On Mon, Dec 27, 2010 at 09:08:14PM +0100, Josselin Mouette wrote:
> Le lundi 27 décembre 2010 à 18:57 +0100, Mike Hommey a écrit : 
> > On Wed, Dec 22, 2010 at 08:36:38PM +0100, Josselin Mouette wrote:
> > > You could use dpkg-trigger to force the trigger to be run after
> > > xulrunner-1.9.1 being installed.
> > 
> > Unfortunately, while some cases were fixed, the original case for which
> > the pre-depends was added fails again :(
> 
> > Yes, the xulrunner-1.9.1 trigger happens right after unpack... before
> > python-xpcom's postinst g. I'm starting to hate dpkg triggers.
> 
> Maybe you want dpkg-trigger --no-await ?

Point is, xulrunner is already installed, thus its postinst is not what
triggers.

Mike


-- 
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/20101227202440.ga30...@glandium.org

squeeze blocker: Bug#606295: libhibernate3-java: FTBFS: maven-related errors

[Julien Cristau]

user release.debian@packages.debian.org
usertag 606295 squeeze-is-blocker
kthxbye

On Fri, Dec 24, 2010 at 00:26:26 +0100, Julien Cristau wrote:

> This needs to be fixed for squeeze, we can't support this package if it
> can't be built; and there's a bunch of reverse dependencies so removal
> looks painful.  Adding debian-java to cc, help is needed to fix
> libhibernate3-java's build.
> 
Now tagging as blocker, and adding -devel to cc, hopefully somebody can
look into this.

> On Sat, Dec 11, 2010 at 13:14:30 -0430, Miguel Landaeta wrote:
> 
> > tags 606295 + confirmed help
> > thanks
> > 
> > On Wed, Dec 08, 2010 at 09:08:48AM +0100, Lucas Nussbaum wrote:
> > > Source: libhibernate3-java
> > > Version: 3.5.4.Final-4
> > > Severity: serious
> > > Tags: squeeze sid
> > > User: debian...@lists.debian.org
> > > Usertags: qa-ftbfs-20101207 qa-ftbfs
> > > Justification: FTBFS on amd64
> > > 
> > > Hi,
> > > 
> > > During a rebuild of all packages in sid, your package failed to build on
> > > amd64.
> > > 
> > > Relevant part:
> > >
> > > [snip]
> > >
> > > > [INFO] Compilation failure
> > > > /build/user-libhibernate3-java_3.5.4.Final-4-amd64-X7BsRy/libhibernate3-java-3.5.4.Final/entitymanager/src/main/java/org/hibernate/ejb/criteria/path/AbstractPathImpl.java:[194,39]
> > > >  invalid inferred types for M; inferred type does not conform to 
> > > > declared bound(s)
> > > > inferred: java.util.Map
> > > > bound(s): java.util.Map
> > 
> > Hi,
> > 
> > The relevant error message is the one shown above.
> > 
> > I suspect this failure is because IcedTea 1.8.2 got more
> > strict with type inference and generics code. I say this
> > since I can rebuild this package without problems with
> > 1.8.1. Thus, this FTBFS is present in sid and squeeze.
> > 
> > This bug seems to be very similar to #602362.
> > The problematic code involves the usage of Java generics and
> > since I'm not very experienced with that kind of code I'm
> > asking for help.
> > 
> > Additionaly, the patch debian-changes-3.5.4.Final-4 included
> > in the last upload seems incorrect to me. It reverts many
> > changes introduced in 3.5.4 to 3.5.2. I think this mistake
> > is due the upstream branch of the git repo where this
> > package is maintained is outdated.
> > 

Cheers,
Julien


signature.asc
Description: Digital signature

Re: Bug#608098: gnome-core: revert mass migration from -desktop-environment to -core

[Holger Levsen]

Hi,

closing the bug as its definitly pointless as wnpp and also as bug against 
gnome.

On Montag, 27. Dezember 2010, Martin-Éric Racine wrote:
> > If you need a specific set of packages, please make your metapackages
> > yourself. See brdesktop-gnome for an example of such a recurrent
> > failure.
> Sorry, but am I the only one who considers this reply as pointlessly
> abrasive, inappropriate and offensive?

well, retitling the bug as Joss did is a bit on the edge of abusing the BTS to 
make a point, but it's also probably still within "having fun with technology 
to express an opinion", esp. given that he also gave valid reasons why he 
considered this bug wontfix already in very same mail, and also in his 2nd 
reply (copied to -devel).

So I'm closing this bug as this he didnt do (yet).

And while I dont like that overworked people sometimes react badly (or less 
good) when people put even more load on them, it's a fact. I also dont like 
that people are overworked in the first place, and thats a fact too. (It's 
also a fact that things doesnt have to be that way..)

It's also a fact that humor sometimes doesnt match. Sadly.

But given the serious answers he also gave (and the retitle-joke itself) I 
dont think this humor was abuse. It was a joke, which some people didnt like 
and some didnt find funny. And some laughed. So what.

Personally (and in the piuparts context) I used to be way more relaxed + 
cheerful replying to people who tell me that (they think) their package had 
valid reasons to violate policy - but sadly over time I've become midly 
annoyed and also bored, that I have to spend my time again+again to explain 
why/that policy is there and also applies to this or that package...


cheers,
Holger


signature.asc
Description: This is a digitally signed message part.

Bug#608150: ITP: routino -- Set of tools to find a path between two points

[Thibaut Gridel]

Package: wnpp
Severity: wishlist
Owner: Thibaut Gridel 

* Package name: routino
  Version : 1.5.1
  Upstream Author : Andrew M. Bishop  
* URL : http://www.routino.org/
* License : AGPL
  Programming Lang: C
  Description : Set of tools to find a path between two points

 Routino is an application for finding a route between two points
 using the dataset of topographical information collected by
 OpenStreetMap.



-- 
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/20101227220241.4917.67944.report...@hertz.maison

Re: Full install/removal/upgrade test results available

[Ian Jackson]

Mike Hommey writes ("Re: Full install/removal/upgrade test results available"):
> Unfortunately, while some cases were fixed, the original case for which
> the pre-depends was added fails again :(
> 
> (starting from xulrunner-1.9.1 already installed, and installing
> python-xpcom, case which I forgot to test before my last uploads)
> Unpacking python-xpcom (from
> .../python-xpcom_1%3a0.0~hg20100212-3_amd64.deb) ...
> Processing triggers for xulrunner-1.9.1 ...
> Obtaining the module object from Python failed.
> 
> : No module named xpcom.server
> Obtaining the module object from Python failed.

So the problem is that python-xpcom does not work when it has been
previously installed, and then during an upgrade the new version has
been unpacked but not configured ?

If you add a dependency from xulrunner to python-xpcom this problem
ought to go away (although if that would lead to a circular dependency
the situation is more complicated as dpkg will need to break the
cycle).

Ian.


-- 
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/19737.10324.139286.394...@chiark.greenend.org.uk

Aprende marinera y festejo este verano 2011 (inicios semanales) . publicidad . iixlg

[Escuela de marinera]

CLASES DE MARINERA
Niños, jóvenes, adultos, señoras y esposos
¡¡Verano 2011!!

-Clases días de semana y sábados
-Clase para niñas desde los 2 años y medio
-Grupos reducidos
-Invitados campeones nacionales

Y sólo por verano: TALLERES DE FESTEJO
-2 veces por semana
-Clases desde las 7:00pm
-Sólo en la sede de La Molina y San Miguel


Asociación Marinera Perú
Dirige. Dora Zapata
- Campeona nacional de marinera en Trujillo
- Campeona nacional en "Coreografía Trujillo 2007"
- Campeona nacional en "Coreografía Trujillo 2010"

LA MOLINA: Plaza Camacho 2do nivel local 14-C Av. Javier Prado Este 5193 
(Frente a Wong) - Telf: 358-7491. 
Email: lamol...@marineraperu.net

SAN MIGUEL: Av. La Marina 2665 Urb. Maranga (Frente a Hiraoka) - Telf: 
578-4812. 
E-mail: sanmig...@marineraperu.net

CHORRILLOS: Centro Comercial Plaza Lima Sur 2do nivel local 263 - Telf: 
784-0003. 
E-mail: chorril...@marineraperu.net



Si no desea recibir más promociones, háganoslo saber respondiendo este email. 
Gracias

Re: Full install/removal/upgrade test results available

[Mike Hommey]

On Mon, Dec 27, 2010 at 11:59:16PM +, Ian Jackson wrote:
> Mike Hommey writes ("Re: Full install/removal/upgrade test results 
> available"):
> > Unfortunately, while some cases were fixed, the original case for which
> > the pre-depends was added fails again :(
> > 
> > (starting from xulrunner-1.9.1 already installed, and installing
> > python-xpcom, case which I forgot to test before my last uploads)
> > Unpacking python-xpcom (from
> > .../python-xpcom_1%3a0.0~hg20100212-3_amd64.deb) ...
> > Processing triggers for xulrunner-1.9.1 ...
> > Obtaining the module object from Python failed.
> > 
> > : No module named xpcom.server
> > Obtaining the module object from Python failed.
> 
> So the problem is that python-xpcom does not work when it has been
> previously installed, and then during an upgrade the new version has
> been unpacked but not configured ?

The remaining problem is that python-xpcom does not work when it was not
previously installed but xulrunner-1.9.1 was.

> If you add a dependency from xulrunner to python-xpcom this problem
> ought to go away (although if that would lead to a circular dependency
> the situation is more complicated as dpkg will need to break the
> cycle).

Plus, xulrunner doesn't need python-xpcom. The problem is that xulrunner
trigger can't work when python-xpcom is only unpacked. It can only work
after python-support trigger has run (or update-python-modules has been
run from python-xpcom postinst, for that matter).

The root of the problem, really, is that python packages can't be used
when only simply unpacked.

Mike


-- 
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/20101228072824.ga3...@glandium.org