Re: dh_config_model_upgrade: package upgrade with Config::Model

[Stefano Zacchiroli]

On Mon, Dec 07, 2009 at 10:57:56PM +0100, Dominique Dumont wrote:
> A model for Config::Model is to a configuration file what a schema is to an 
> XML file: a description of the structure and constraint of the semantic data 
> of the file. 

Fair enough. So, in your terminology, a model is the schema. How do you
call instances? I'll use "instances" in the rest of this mail :-) Now
that that is clear, which kind of migrations of configuration file can
you provide on top of Config::Model.

Given that models contain default values, I believe it would be pretty
easy to provide change of default values, it would be enough to change
them in m_{i+1}, right?

Still, my recurring question has left unanswered, I swear this is the
last time I pose it. Does Config::Model permit to *programmatically*
apply more complex modification at upgrade time? Let's say I want to, at
the same time during an upgrade:

- change a default value from "yes" to "no"
- add 1 to a given set of integer values wrt what the user configured by
  hand (e.g. because there was an off-by-one sort of semantics in past
  upstream configuration, which has been changed now)

The second case is a bit more tricky, because you can easily fix default
values, but you really want to fix also user-customized values.

To achieve that, Config::Model would need to provide me (as the package
maintainer) the ability to write a small perl snippet where I've access
to the currently installed configuration file (which conforms to the old
version of the model, let's say m_i), where I can migrate it to the new
version of the model (let's say m_{i+1}), and also manipulate it as a
tree to change the values I want.

This of course is just an example, my general question was whether I can
only migrate from m_i to m_{i+1} or also pipe in between some custom
programmed logics.

TIA.
Cheers.

-- 
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
z...@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..|  .  |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...| ..: | Je dis tu à tous ceux que j'aime


signature.asc
Description: Digital signature

Re: Update about "3.0 (quilt)" source format

[Raphael Hertzog]

Hi,

On Mon, 07 Dec 2009, Peter Samuelson wrote:
> Maybe I missed something from earlier discussion - but why not rename
> debian/source/patch-header to debian/patches/debian-changes?  (I mean,
> dpkg-source would preserve the header when regenerating the file, like
> quilt does, right?)

No, it currently doesn't preserve the header of the automatic patch. Given
that dpkg-source can remove that file when there are no longer any
(further) upstream changes, I don't consider it as viable place to store
that information.

> And the existence of that patch file should already imply the
> --single-debian-patch flag.

I don't like when the behaviour is implicitely defined. I prefer
the situation where it's explicitely selected by the maintainer
and where it appears in the build log on the line "using options from
debian/source/options: %s".

Also the patch-header is used for all automatic patches (whether or not
--single-debian-patch is used) including for the (not-to-be-used in
Debian) 2.0 format.

Cheers,
-- 
Raphaël Hertzog


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Should ucf be of priority required?

[Manoj Srivastava]

On Mon, Dec 07 2009, Joe Smith wrote:

> I suspect Patrick might be worried about a scenario like the following.
>
> Lets assume there is a package Foo that depends on and uses
> ucf. Further the package is the only one ucing UCF on the system.
>
> At some point the admin decides to remove Foo. Since there are no
> other packages that use ucf on this hypothetical system, the admin
> also chooses to remove ucf.
>
> The admin purges Foo, but not ucf. Later the user installs some other
> package that uses ucf.

> The net result here is that ucf may be keeping excess state related to
> package foo.

But it is not. ucf knows well that when it is reinstalled the
 state information can't be trusted, it is merely historical, and takes
 steps to preserve, but not trust, that data.

> Since it was not around to be alerted when Foo was purged, ucf is
> unaware that this excess data may no longer needed. Thus any state of
> ucf related to the package Foo will live on until some point when ucf
> is purged, or perhaps if Foo is reinstalled, and then re-removed and
> re-purged.

That would have been very bad design, and  a bug.

> On the other hand, had the admin purged ucf at the same time that he
> purged Foo, when ucf was reinstalled later it would start from a clean
> slate and not keep around this old state that is not terribly useful
> anymore.

And lose all historical data about the state of the system. I
 prefer to not throw away information when it can reasonably be kept.

> Now I'm not familar enough with ucf to know if this is a real
> possibility. Perhaps ucf's design has something to prevent such a
> thing from occuring.

It is not a possibility. 


> I'm not sure.

Then perhaps asking, rather than  insisting on breaking
 encapsulation, should be the first thing to try to do?  Either read the
 code, or ask first?

> It certainly sounds like a plausible way to leak disk space.

And again, ucf has a limit on the historical data that it
 keeps.  Next?

manoj
 not really a novice in software design anymore.
-- 
Pudder's Law: Anything that begins well will end badly. (Note: The
converse of Pudder's law is not true.)
Manoj Srivastava    
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#559988: ITP: cruisecontrol -- continuous integration and build tool

[Onkar Shinde]

Package: wnpp
Severity: wishlist
Owner: Onkar Shinde 


* Package name: cruisecontrol
  Version : 2.8.2
  Upstream Author : cruisecontrol-de...@lists.sourceforge.net
* URL : http://cruisecontrol.sourceforge.net/
* License : BSD (3 clause) like
  Programming Lang: Java
  Description : continuous integration and build tool

CruiseControl is both a continuous integration tool and an extensible framework 
for creating a custom continuous build process. It includes dozens of plugins 
for a variety of source controls, build technologies, and notifications schemes 
including email and instant messaging. A web interface provides details of the 
current and previous builds.



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#559987: ITP: libmodule-install-xsutil-perl -- Module::Install extension for handling XS modules

[Jonathan Yu]

Package: wnpp
Owner: Jonathan Yu 
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org,debian-p...@lists.debian.org

* Package name: libmodule-install-xsutil-perl
  Version : 0.19
  Upstream Author : Goro Fuji 
* URL : http://search.cpan.org/dist/Module-Install-XSUtil/
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : Module::Install extension for handling XS modules

Module::Install::XSUtil is a Perl module which extends Module::Install by
providing a set of utilities to setup distributions which include or depend
on XS module.

For examples of this module in action in the wild, see XS::MRO::Compat and/or
Method::Cumulative.



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#559984: ITP: libb-hooks-op-annotation-perl -- module to allow annotation and delegation of hooked OPs

[Jonathan Yu]

Package: wnpp
Owner: Jonathan Yu 
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org,debian-p...@lists.debian.org

* Package name: libb-hooks-op-annotation-perl
  Version : 0.43
  Upstream Author : chocolateboy 
* URL : http://search.cpan.org/dist/B-Hooks-OP-Annotation/
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : module to allow annotation and delegation of hooked OPs

B::Hooks::OP::Annotation provides a way for XS code that hijacks OP op_ppaddr
functions to delegate to (or restore) the previous functions, whether they
are assigned by perl or by another module. Typically this should be used in
conjunction with B::Hooks::OP::Check (see libb-hooks-op-check-perl).

B::Hooks::OP::Annotation makes its types and functions available to XS code
by means of ExtUtils::Depends (libextutils-depends-perl). Modules that wish
to use these exports in their XS code should use B::OP::Hooks::Annotation in
the Perl module that loads the XS.



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Should ucf be of priority required?

[Joe Smith]

I suspect Patrick might be worried about a scenario like the following.

Lets assume there is a package Foo that depends on and uses ucf. Further the 
package is the only one ucing UCF on the system.


At some point the admin decides to remove Foo. Since there are no other 
packages that use ucf on this hypothetical system, the admin also chooses to 
remove ucf.


The admin purges Foo, but not ucf. Later the user installs some other 
package that uses ucf.


The net result here is that ucf may be keeping excess state related to 
package foo. Since it was not around to be alerted when Foo was purged, ucf 
is unaware that this excess data may no longer needed. Thus any state of ucf 
related to the package Foo will live on until some point when ucf is purged, 
or perhaps if Foo is reinstalled, and then re-removed and re-purged.


On the other hand, had the admin purged ucf at the same time that he purged 
Foo, when ucf was reinstalled later it would start from a clean slate and 
not keep around this old state that is not terribly useful anymore.


Now I'm not familar enough with ucf to know if this is a real possibility. 
Perhaps ucf's design has something to prevent such a thing from occuring. 
I'm not sure. It certainly sounds like a plausible way to leak disk space. 




--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: DEP-5: removed files

[Charles Plessy]

Le Mon, Dec 07, 2009 at 12:26:52AM -0800, Steve Langasek a écrit :
> On Wed, Dec 02, 2009 at 03:56:51PM +0100, Thibaut Paumard wrote:
> 
> > I remember that debian/copyright should not only list where the
> > source was downloaded from, but also the files which were removed by
> > the packager and the motivation for the removal (DFSG, patents,
> > large convenience copy of a library...). At least, that's how I
> > interpret this (from [1], I cannot find an excerpt from policy):
> 
> > "3) Include a description of how you obtained the upstream source
> > tarball. This should be sufficient for anybody to duplicate the
> > process immediately, but don't worry too much if it isn't (eg, the
> > server is not public or no longer accessible)."
> 
> This is not a requirement of Debian Policy; there are two other ways that
> Policy already recommends communicating this information:
> 
>  - in the debian/README.source file
>  - by way of a get-orig-source target in debian/rules
> 
> Providing the same information in debian/copyright would be redundant, and
> should be avoided.
 
> Given that Policy says to put this elsewhere than debian/copyright, I don't
> think it makes sense for DEP-5 to specify such sections; this is probably
> better addressed by including support for free-form comments, as suggested
> elsewhere.

Dear Thibaut and Steve,

Given that the purpose of DEP-5 is to make information available to machines,
my feeling is also that there is no need for a new field, unless there is a
commitemnt to parse the license information about removed files in a
programmatic way.

While duplication of information should be avoided, there are still a couple of
justifications why the license of removed files could be summarised. First,
most get-orig-source targets in debian/rules let the removed files transit on
the user's machine. Similarly, some VCS that are available through
‘debcheckout’ also contain a copy of the removed files in their upstream
branch. For these cases, I think that debian/copyright is a relevant place to
declare the license of the removed files, since they may actually be really
there!

In addition to free-form comments, my understanding of DEP-5 is that it is open
in the similar way as mail headers. Therefore a group of people, for instance a
packaging team, can federate on a more formal representation than free-form
comments if they like. I would therefore recommend to Thibaut to experiment a
bit on different possible implementations if free-form comments are not enough.
If there is interest I can contribute ideas: I was actually trying to draft a
similar enhancement last September.

By the way, there was an interesting discussion in bugs.debian.org/521810 a
couple of monthes ago, which ended on the conclusion that adding a “X-” prefix
on extra fields in Debian control files does not bring much benefit. I propose
to apply this to DEP-5:

  ### Extra fields.
  
  Extra fields can be added to any section. It is not recommended to prefix 
their
  name by **`X-`**.

I hope it can contribute to ease experimentation.

Have a nice day,

-- 
Charles Plessy
Tsurumi, Kanagawa, Japan


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: New Menu category Applictions/Multimedia

[Paul Wise]

On Tue, Dec 8, 2009 at 12:50 AM, Andreas Marschke
 wrote:

> I haven't had the freedesktop.org in mind at the time of writing it but yes it
> is infact a reason to do this as well.
> The bug is filed and should be open for broader discussion soon.

You should have chosen wishlist severity for the bug (#559895) btw,
please fix that:

http://www.debian.org/Bugs/server-control

> Should I file the lintian bug too? Or will this have to wait till the fix is
> gone into menu?

Wait until menu has changed.

Thinking about it a bit more, the lintian one probably isn't needed
unless the old categories are to go away.

>> Please note that the Debian menu is not shown by Debian GNOME by
>> default. IIRC LXDE doesn't support it either.
>
> Is this something specific to the gnome/lxde setup in Debian? If so should we
> file a bug  against it?
> I discovered this in KDE as well as fluxbox .

Upstream desktops only support the FreeDesktop menu, GNOME in Debian
supports the Debian menu but has it turned off by default. You'll have
to check the mailing list archives for the actual rationale, but I
think it was because users were getting confused by two menus and
making Debian more like other distros.

http://lists.debian.org/debian-devel/2008/07/threads.html#00107

LXDE is a new desktop I guess the maintainers have not yet had time to
add support for the Debian menu (see #517190 for more). Here is a
thread about it too:

http://lists.debian.org/debian-devel/2009/02/thrd2.html#00809

I also heard rumblings that the KDE maintainers were going to remove
the Debian menu too.

Personally I think we should have gotten rid of the Debian menu years
ago, I don't think my opinion is shared by many people in Debian
though.

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: dh_config_model_upgrade: package upgrade with Config::Model

[Dominique Dumont]

Le vendredi 4 décembre 2009 17:48:00, Stefano Zacchiroli a écrit :
> Well, reading your posts I understand there is in fact a
> misunderstanding. The question mentioned in the reported wiki page has
> nothing to do with a debconf question: is the question posed by dpkg
> when there is a mismatch between an on-disk configuration file and the
> old version of the maintainer configuration file. Try re-reading the
> wiki page with that in mind to see if it makes a bit more sense (it does
> to me at least).


Well, I may have not been very clear about debconf usage with Config::Mode in 
the Wiki.

I see 2 ways for Config::Model to use Debconf:

1. As proposed in the beginning of this thread, use debconf to ask a global 
question whether to use Config::Model or not. As mentioned by Stefano, this is 
a good idea. I agree (now) so I'll remove this part

2. Use Debconf to query missing configuration data (i.e. a mandatory value 
without default value). But we're not there yet.
 
> > Where is the Model?
> > Who designs the Model?
> 
> These are question I've posed my self already in the thread. Again, can
> we please leave the proposer the time to reply to those? Merely
> repeating the questions will not help :-)

In this case, the Model can be written by the upstream project, or by the 
packager. But each model is dedicated to an application. I grant you that's 
quite an effort, but not much more than writing a lens for Augeas. An Augeas 
has already quite of lot of lenses written by the community. So this kind of 
effort is possible by the same kind of community. Now, it's up to me to 
convince this community that providing configuration upgrade ( and 
configuration GUI ) is worth the effort. 
 
> > 'Model' seems to be a completely misleading use of terminology. Why was
> > it chosen?
> 
> I believe the author is using the model term in the same it is used in
> model-driven engineering [1]. *If* it is the case (I don't actually know
> if it is, but with that assumption in mind the terminology makes sense),
> a model is essentially an "abstract syntax tree"-like representation of
> a specific configuration file. Furthermore, classes of configuration
> file have a grammar in common (or "meta-model", in MDE terminology).

A model for Config::Model is to a configuration file what a schema is to an 
XML file: a description of the structure and constraint of the semantic data 
of the file. 

That's big talk. So here's a very simple example extracted from Sshd model. 
This example describes the TCPKeepAlive parameter:

'TCPKeepAlive' =>
   {
 'value_type' => 'enum',
 'help' => {
  'yes' => 'Send TCP keepalive messages. The server will notice if 
the network goes down or the client host crashes. This avoids infinitely 
hanging sessions.',
   'no' => 'disable TCP keepalive messages'
   },
 'upstream_default' => 'yes',
 'type' => 'leaf',
 'description' => 'Specifies whether the system should send TCP keepalive 
messages to the other side. If they are sent, death of the connection or crash 
of one of the machines will be properly noticed. However, this means that 
connections will die if the route is down temporarily, and some people find it 
annoying.  On the other hand, if TCP keepalives are not sent, sessions may 
hang indefinitely on the server, leaving "ghost" users and consuming server 
resources. This option was formerly called KeepAlive.',
  'choice' => ['no','yes']
},


> > Is the model package specific or system-wide?
> 
> According to the above assumptions, a model is just an abstract version
> of a specific config file, with some specific data in it. 
> A meta-model is specific of a whole class of configuration files (e.g. 
fstab, apache conf-file, postfix map file, etc.).

A configuration model is like a set of Class definition in C++, and the 
configuration tree is an instance of the root class in the model. There are 
like a set of configuration objects arranged in a tree structure from the 
model (the set of classes)

All the best

Dominique
--
http://config-model.wiki.sourceforge.net/ -o- http://search.cpan.org/~ddumont/
http://www.ohloh.net/accounts/ddumont


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: dh_config_model_upgrade: package upgrade with Config::Model

[Dominique Dumont]

Le vendredi 4 décembre 2009 20:08:57, gregor herrmann a écrit :
> Since you speak French you might be interested in Dominique's
> presentation at some French Perl meeting:
> http://fpw2009.ubicast.eu/videos/free/64/

Today, I've recorded today an English version of this presentation (with some 
enhancements to the slide set). I should be able to make it available next 
week (I need to compress the 12GB DV file into something more manageable ;-) )

All the best

Dominique
--
http://config-model.wiki.sourceforge.net/ -o- http://search.cpan.org/~ddumont/
http://www.ohloh.net/accounts/ddumont


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Policy conformant conffile handling...

[Frank Küster]

Steve Langasek  wrote:

> On Thu, Dec 03, 2009 at 11:40:06AM +0100, Frank Küster wrote:
>> However, and here's the policy-related problem: Of course the admin
>> might have changed the default paper for one particular binary
>> manually. What should I do in this case?
>
> [...]
>
>> - let libpaper's setting overwrite everything: Probably not intended;
>>   not policy-compliant
>
> Is texconfig being called from maintainer scripts?

In this case, at least indirectly; since I would drop a script into
/etc/libpaper.d/ that calls "texconfig paper $(paperconf -n -d)"

> Using the 'include' capabilities for anything that supports it would surely
> still be better, though.

That's not possible for many of the binaries involved.  


@ the TeX list mainly

There's only one use case where *not* setting the paper according to the
system paper actually causes problems, and that is when directly
printing from the command line.  Once a PDF is generated, the PDF viewer
will usually be used for printing, and will have options to deal with
paper mismatches.

In other words, it's mainly dvips that's we need to cater for.  Is there
an include mechanism for dvips, or a way to override settings in
config.ps for all printers?

Regards, Frank
-- 
Dr. Frank Küster
Debian Developer (TeXLive)
VCD Aschaffenburg-Miltenberg, ADFC Miltenberg
B90/Grüne KV Miltenberg


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Bug#559802: CVE-2009-3736 local privilege escalation

[Steve Langasek]

On Mon, Dec 07, 2009 at 08:56:07AM +0100, Stefan Hornburg (Racke) wrote:
> >CVE-2009-3736[0]:
> >| ltdl.c in libltdl in GNU Libtool 1.5.x, and 2.2.6 before 2.2.6b,
> >| attempts to open a .la file in the current working directory, which
> >| allows local users to gain privileges via a Trojan horse file.

> >Note that this problem also affects etch and lenny, so if your package
> >is affected, please coordinate with the security team to release the
> >DSA for the affected packages.

> >If you fix the vulnerability please also make sure to include the
> >CVE id in your changelog entry.

> Is there a patch available for the vulnerability?

The patch is to not use embedded copies of libltdl, we have a system libltdl
that all packages should be using.

It appears that courier-authlib is already doing this.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: Digital signature

Re: Should ucf be of priority required?

[Manoj Srivastava]

On Mon, Dec 07 2009, Patrick Schoenfeld wrote:

> Hi,
>
> (uhm.. I really hate it, if I can't hold the promises to myself I made;
> in this case: not further discussing it, but still here is
> another answer)
>
> On Mon, Dec 07, 2009 at 10:04:14AM -0600, Manoj Srivastava wrote:
>> On Mon, Dec 07 2009, Patrick Schoenfeld wrote:
>> 
>> > On Sun, Dec 06, 2009 at 11:47:11PM -0600, Manoj Srivastava wrote:
>> >> >> In this particular case, what is the harm befalling the user?
>> >> >
>> >> > Well, I don't think that making an Operating System is just about
>> >> > keeping harm away from our users.
>> >> 
>> >> But it is a tenet of software design that to change something
>> >>  that is working,  you have to have some justification beyond I wish
>> >>  things were different.
>> >
>> > Making the software better, in this case.
>> 
>> Again, you make an assertion, without any basis for it. Why is
>>  it better, apart from the fact you seem to think it would be? What use
>>  case is being negatively impacted?
>
> Yes, I do make an assertion. But not "without any basis". Its just not a
> basis that you accept.
>
> All boils down to the points where we disagree the most:
> - I consider data that is used *nowhere* as garbage. You think its not
>   garbage, because you could use it some time in the future.

Right.

> - I consider ucf just a tool doing a certain duty on behalf of the
>   package requesting it.

Yup. The task is to ask the user about how they want to handle
 what is done to files when the package is being upgraded.

>   For me this assumes that data created during this task belongs to
>   the package that requested the creation of the data in the first
>   place.

That breaks abstraction and encapsulation.

>   And it includes providing an interface that does exactly what
>   is it told to do.

Sorry. This is not the software paradigm you are looking for. In
 keeping with modular (and object oriented) design, ucf provides certain
 facilities. It keeps internal state, but that is opaque to the user.

>   For you the data belongs to ucf and it can do with it whatever it
>   wants to do. So if a postrm requested to purge the file from the
>   database it would also be okay, if ucf didn't do that.

Nope. No other package gets to muck around with the internal
 structures and data for any utility, and that includes files hidden
 from the application. The API is provided for a purpose: use it, and do
 not break encapsulation by delving into internal details of the
 implementation. 


> Apart from this you made clear that you don't want to discuss your
> software design, because "its not my business". Good to know.

No, I meant it is not the business of any application that uses
 the interfaces that ucf provides.

I'll be happy to discuss the design. I'll be even happier to
 support any use cases you can bring up and advocate.

> I won't go further trying to change what I think is wrong. You as the
> ucf maintainer decided that collecting garbage is okay, because
> its not garbage in your opinion. Most other people agreed to that or
> didn't comment at all (including those persons who agree with me).
> It doesn't matter anyway. Its been a corner case from the beginning,
> a seldom one additionally. There is work on-going or at least planned
> to merge ucf functionality into dpkg, which is the better solution
> IMHO anyway and will probably fix my "problem".

I was not aware that dpkg was going to expand and work with non
 conffiles: most of the work is for providing ucf-like handling of
 conffiles, not for configuration files, unless I am misreading
 something.

> You won't change my mind. I will not change your mind.
> So to save us from discussing the topic to death, let us just agree to
> disagree, ok? 

That's a cop out. It is, as you said, my package, and I will
 listen to people pointing out what are flaws, but I reserve the
 right to also say why it is not a flaw.

As I see it,  internal state of a utility is its own, and the
 very reason it provides an API is to abstract the functionality (so
 internal implementation can change), encapsulate internal state and
 data (so other applications and users don't have to worry about how
 things are implemented).

If any supported use cases are broken, that would be a bug. I do
 not see there is indeed a bug.

manoj
-- 
The hearing ear is always found close to the speaking tongue, a custom
whereof the memory of man runneth not howsomever to the contrary, nohow.
Manoj Srivastava    
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Should ucf be of priority required?

[Patrick Schoenfeld]

Hi,

(uhm.. I really hate it, if I can't hold the promises to myself I made;
in this case: not further discussing it, but still here is
another answer)

On Mon, Dec 07, 2009 at 10:04:14AM -0600, Manoj Srivastava wrote:
> On Mon, Dec 07 2009, Patrick Schoenfeld wrote:
> 
> > On Sun, Dec 06, 2009 at 11:47:11PM -0600, Manoj Srivastava wrote:
> >> >> In this particular case, what is the harm befalling the user?
> >> >
> >> > Well, I don't think that making an Operating System is just about
> >> > keeping harm away from our users.
> >> 
> >> But it is a tenet of software design that to change something
> >>  that is working,  you have to have some justification beyond I wish
> >>  things were different.
> >
> > Making the software better, in this case.
> 
> Again, you make an assertion, without any basis for it. Why is
>  it better, apart from the fact you seem to think it would be? What use
>  case is being negatively impacted?

Yes, I do make an assertion. But not "without any basis". Its just not a
basis that you accept.

All boils down to the points where we disagree the most:
- I consider data that is used *nowhere* as garbage. You think its not
  garbage, because you could use it some time in the future.
- I consider ucf just a tool doing a certain duty on behalf of the
  package requesting it. For me this assumes that data created during
  this task belongs to the package that requested the creation of the
  data in the first place. And it includes providing an interface that
  does exactly what is it told to do. For you the data belongs to ucf
  and it can do with it whatever it wants to do. So if a postrm
  requested to purge the file from the database it would also be okay,
  if ucf didn't do that.

Apart from this you made clear that you don't want to discuss your
software design, because "its not my business". Good to know.

I won't go further trying to change what I think is wrong. You as the
ucf maintainer decided that collecting garbage is okay, because
its not garbage in your opinion. Most other people agreed to that or
didn't comment at all (including those persons who agree with me).
It doesn't matter anyway. Its been a corner case from the beginning,
a seldom one additionally. There is work on-going or at least planned
to merge ucf functionality into dpkg, which is the better solution
IMHO anyway and will probably fix my "problem".

You won't change my mind. I will not change your mind.
So to save us from discussing the topic to death, let us just agree to
disagree, ok? 

Best Regards,
Patrick


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: New Menu category Applictions/Multimedia

[Andreas Marschke]

Am Montag 07 Dezember 2009 04:35:30 schrieb Paul Wise:
> On Mon, Dec 7, 2009 at 3:34 AM, Andreas Marschke  
wrote:
> > I'm hereby proposing an additional Category for this list of such
> > applications called Multimedia. This defines clearer what they are.
> 
> Sounds reasonable to me, this would bring the Debian menu closer to
> the FreeDesktop menu, which has AudioVideo and more specific
> sub-categories. I'd suggest filing a bug on the menu package and maybe
> lintian once menu is added.
I haven't had the freedesktop.org in mind at the time of writing it but yes it 
is infact a reason to do this as well. 
The bug is filed and should be open for broader discussion soon.  

Should I file the lintian bug too? Or will this have to wait till the fix is 
gone into menu? 

> Please note that the Debian menu is not shown by Debian GNOME by
> default. IIRC LXDE doesn't support it either.
Is this something specific to the gnome/lxde setup in Debian? If so should we 
file a bug  against it? 
I discovered this in KDE as well as fluxbox .


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Should ucf be of priority required?

[Manoj Srivastava]

On Mon, Dec 07 2009, Patrick Schoenfeld wrote:

> On Sun, Dec 06, 2009 at 11:47:11PM -0600, Manoj Srivastava wrote:
>> >> In this particular case, what is the harm befalling the user?
>> >
>> > Well, I don't think that making an Operating System is just about
>> > keeping harm away from our users.
>> 
>> But it is a tenet of software design that to change something
>>  that is working,  you have to have some justification beyond I wish
>>  things were different.
>
> Making the software better, in this case.

Again, you make an assertion, without any basis for it. Why is
 it better, apart from the fact you seem to think it would be? What use
 case is being negatively impacted?

> But this is quiet abstract in this case, because this is not changing
> the design of a specific tool, its about making the tool *always*
> perform its duties.

The tool is always performing its duties, really.  What it needs
 to do depends on state, and the environment, which you don't  take into
 account. 

>> > In this case there is not even almost a reason to keep the data.
>> 
>> The package that calls ucf does not get to decide this.
>
> No, thats wrong. The package that calls ucf does already decide this,
> in the moment it gets purged and calls out to ucf to let it remove
> this data, because its not used anymore. The usual case if ucf is
> installed.

No. It does not decide what ucf does. It does not decide that
 ucf actually does anything; or puts it into a RDBMS, or into a file, or
 ignores it. All it does is to make a call to ucf. ucf decides how to
 handle the call, or whether even to offer the interface.


> Well, its a fact. ucf does not need this data, the package does not need
> that data. Not even the administrator needs that data.

True. But  when the internal staate information is discarded
 depends on ucf. It can keep the data around for historical reasons if
 it wants.

>> If ucf does something wrong with it,
>>  point it out, and file a bug.
>
> I never said that ucf does something wrong. I said that it does not
> have the chance to do its duties.

And I say it does do its duties. Point me to what duties are
 failed as far as its use case actors are concerned (don't talk to me
 about internal details of the abstraction, which are none of your
 business). 

> Well, in this point we simply disagree. The data in question is not
> needed by ucf at this point. In fact ucf would never have needed this
> data, if the package wasn't installed in the first place. And even
> since it has been installed the data has more relevance to the package
> itself, because ucf is just a tool to aid the maintainer scripts in
> getting a job done.

And ucf gets to decide what it does with its internal state
 information. It can keep data no longer needed if it wants,  for
 historical purposes (and tomorrow, provide a log of activities -- not
 that I am promising to code that). Stay the hell out of the internal
 details of the service, and how it provides the functionality beneath
 it's API.


> And the fact that purging a package, which uses ucf, usually would
> remove the data from the ucf registry as well weakens your point.
> If it would belong to ucf why bother with removing it at all?

usually, ucf would be in a different part of its internal state
 diagram, and its behaviour would be different. ucf gets to decide how
 it behaves in different internal states with respect to internal state
 data.


manoj

-- 
The system was down for backups from 5am to 10am last Saturday.
Manoj Srivastava    
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Bug#559802: CVE-2009-3736 local privilege escalation

[Steffen Joeris]

Hi


> > > The following CVE (Common Vulnerabilities & Exposures) id was
> > > published for libtool.  I have determined that this package embeds a
> > > vulnerable copy of the libtool source code.  However, since this is a
> > > mass bug filing (due to so many packages embedding libtool), I have not
> > > had time to determine whether the vulnerable code is actually present
> > > in any of the binary packages. Please determine whether this is the
> > > case. If the package is not affected, please feel free to close the bug
> > > with a message containing the details of what you did to check.
> > >
> > > CVE-2009-3736[0]:
> > > | ltdl.c in libltdl in GNU Libtool 1.5.x, and 2.2.6 before 2.2.6b,
> > > | attempts to open a .la file in the current working directory, which
> > > | allows local users to gain privileges via a Trojan horse file.
> > >
> > > Note that this problem also affects etch and lenny, so if your package
> > > is affected, please coordinate with the security team to release the
> > > DSA for the affected packages.
Is this different to all these python modules that include the working 
directory? When I had a quick look it smelled like these once, in which case 
none of the packages probably deserves a DSA and they can all be fixed through 
s-p-u/o-s-p-u (and can be urgency 'slow'), but I thought I'd ask first in case 
I misunderstood the issue.

Cheers
Steffen


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Bug#559802: CVE-2009-3736 local privilege escalation

[Michael Gilbert]

On Mon, 07 Dec 2009 08:56:07 +0100, Stefan Hornburg (Racke) wrote:
> Michael Gilbert wrote:
> > Package: courier-authlib
> > Severity: grave
> > Tags: security
> > 
> > Hi,
> > 
> > The following CVE (Common Vulnerabilities & Exposures) id was
> > published for libtool.  I have determined that this package embeds a
> > vulnerable copy of the libtool source code.  However, since this is a
> > mass bug filing (due to so many packages embedding libtool), I have not
> > had time to determine whether the vulnerable code is actually present
> > in any of the binary packages. Please determine whether this is the
> > case. If the package is not affected, please feel free to close the bug
> > with a message containing the details of what you did to check.
> > 
> > CVE-2009-3736[0]:
> > | ltdl.c in libltdl in GNU Libtool 1.5.x, and 2.2.6 before 2.2.6b,
> > | attempts to open a .la file in the current working directory, which
> > | allows local users to gain privileges via a Trojan horse file.
> > 
> > Note that this problem also affects etch and lenny, so if your package
> > is affected, please coordinate with the security team to release the
> > DSA for the affected packages.
> > 
> > If you fix the vulnerability please also make sure to include the
> > CVE id in your changelog entry.
> > 
> 
> Is there a patch available for the vulnerability?

Yes, if you follow the link to the mitre page [0], which was included
in the original bug report, you will find a link to the patches [1].

Best wishes,
Mike

[0] http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-3736
[1] 
http://git.savannah.gnu.org/cgit/libtool.git/commit/?h=branch-1-5&id=29b48580df75f0c5baa2962548a4c101ec7ed7ec


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Update about "3.0 (quilt)" source format

[Peter Samuelson]

[Raphael Hertzog]
> In the same version, a new option --single-debian-patch has been
> created so that people using a VCS can have dpkg-source create and
> auto-update a single patch named debian-changes (instead of
> debian-changes-version) somewhat similar to what the .diff.gz was in
> format 1.0 while still benefiting from the other features (bzip2
> compression, multiple tarballs, etc.). It is possible to set the
> header of this automatic patch in debian/source/patch-header and thus
> you can explain there where the changes can be better reviewed (most
> likely somewhere in the VCS).

Maybe I missed something from earlier discussion - but why not rename
debian/source/patch-header to debian/patches/debian-changes?  (I mean,
dpkg-source would preserve the header when regenerating the file, like
quilt does, right?)  And the existence of that patch file should
already imply the --single-debian-patch flag.
-- 
Peter Samuelson | org-tld!p12n!peter | http://p12n.org/


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Bug#559774: ITP: modem-cmd -- send arbitrary AT commands to your modem

[Robert Millan]

On Mon, Dec 07, 2009 at 09:28:03AM +0100, Josselin Mouette wrote:
> Le lundi 07 décembre 2009 à 01:43 +0100, Robert Millan a écrit : 
> > modem-cmd can be used to send arbitrary AT commands to a modem device
> >  over a serial line.
> >  .
> >  For example:
> >  .
> >  $ modem-cmd /dev/ttyUSB0 ATDT123456
> 
> I don’t really see the point in packaging a 10-line shell script.

It's not a shell script...

Anyhow, the point is very simple: users sometimes find themselves in need of
a simple dialer program, just like I did, and they tend to get utterly
confused (just like I got):

  http://www.mail-archive.com/debian-u...@lists.debian.org/msg85161.html

For me, the simplest solution was to derive the interface expected by the
modem by stracing cu, and writing a small C program that implements it.

> OTOH packaging vmcp[1] could be more useful, since it can also send
> files, e.g. to control voice modems.
> 
> [1] http://www.unix.gr/gsm/voice/vmcp.c

I'd appreciate if you do.

-- 
Robert Millan

  The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
  how) you may access your data; but nobody's threatening your freedom: we
  still allow you to remove your data and not access it at all."


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Bug#559774: ITP: modem-cmd -- send arbitrary AT commands to your modem

[Robert Millan]

On Mon, Dec 07, 2009 at 02:14:52AM +, Ben Hutchings wrote:
> On Mon, 2009-12-07 at 01:43 +0100, Robert Millan wrote:
> > Package: wnpp
> > Severity: wishlist
> > Owner: Robert Millan 
> > 
> > * Package name: modem-cmd
> >   Version : 0.0.1
> >   Upstream Author : me
> > * URL : none yet, debian-native
> 
> Why should this be Debian-specific?

I don't know.  Should it?

> >  $ modem-cmd /dev/ttyUSB0 ATDT123456
> 
> Which I can trivially can do with stty and echo already, no?

I looked at stty, and its interface doesn't seem any simpler than programming
termios directly.  See also my other reply on flushing buffers.

-- 
Robert Millan

  The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
  how) you may access your data; but nobody's threatening your freedom: we
  still allow you to remove your data and not access it at all."


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Update about "3.0 (quilt)" source format

[Raphael Hertzog]

Hello,

This is going to be part of the next "Misc Developer News" on d-d-a but
since it likely going to take some time until we reach 5 items, I share it
on -devel right now.

---
Since dpkg 1.15.5.4, dpkg-source creates the .pc directory used by quilt
by itself (even if quilt is not available), it also relies on
.pc/applied-patches to know what patches are applied or not. It is thus
100% compatible with quilt and the option --without-quilt is thus gone.

In the same version, a new option --single-debian-patch has been created
so that people using a VCS can have dpkg-source create and auto-update a
single patch named debian-changes (instead of debian-changes-version)
somewhat similar to what the .diff.gz was in format 1.0 while still
benefiting from the other features (bzip2 compression, multiple tarballs,
etc.). It is possible to set the header of this automatic patch in
debian/source/patch-header and thus you can explain there where the
changes can be better reviewed (most likely somewhere in the VCS). 
---

Since the first change is a rather big change in the behaviour
and logic, I wanted to highlight it in the hope to catch any potential
problem quickly.

To completely avoid problems with buildd unpacking source packages outside
of the build chroot we would need to backport that change in lennny, I
might do that once the current code has been (satisfactorily) in use in
sid.

Cheers,
-- 
Raphaël Hertzog


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Bug#559802: CVE-2009-3736 local privilege escalation

[Stefan Hornburg (Racke)]

Michael Gilbert wrote:

Package: courier-authlib
Severity: grave
Tags: security

Hi,

The following CVE (Common Vulnerabilities & Exposures) id was
published for libtool.  I have determined that this package embeds a
vulnerable copy of the libtool source code.  However, since this is a
mass bug filing (due to so many packages embedding libtool), I have not
had time to determine whether the vulnerable code is actually present
in any of the binary packages. Please determine whether this is the
case. If the package is not affected, please feel free to close the bug
with a message containing the details of what you did to check.

CVE-2009-3736[0]:
| ltdl.c in libltdl in GNU Libtool 1.5.x, and 2.2.6 before 2.2.6b,
| attempts to open a .la file in the current working directory, which
| allows local users to gain privileges via a Trojan horse file.

Note that this problem also affects etch and lenny, so if your package
is affected, please coordinate with the security team to release the
DSA for the affected packages.

If you fix the vulnerability please also make sure to include the
CVE id in your changelog entry.



Is there a patch available for the vulnerability?

I don't know which modifications were applied upstream to the libtool
copy.

Regards
 Racke


--
LinuXia Systems => http://www.linuxia.de/
Expert Interchange Consulting and System Administration
ICDEVGROUP => http://www.icdevgroup.org/
Interchange Development Team


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Should ucf be of priority required?

[Wouter Verhelst]

On Sun, Dec 06, 2009 at 01:17:30PM +0100, Patrick Schoenfeld wrote:
> On Sat, Dec 05, 2009 at 12:39:28PM -0800, Steve Langasek wrote:
> > There's no reason that ucf *should* fall under either of these rules; so
> > even if ucf /didn't/ work the way it does, the right solution here would be
> > to fix it so that it did, not to add it to Essential.
> 
> Makes sense. But how do you fix a package to do what its supposed to do,
> when it isn't installed anymore?

You don't need to. When the package is purged, and ucf doesn't exist
anymore, what you do is rm -f the relevant files.

Unregistering those files in ucf is necessary so that ucf throws away
the correct checksums from its database, too. However, if ucf itself is
no longer on the system, then the same is true for that database, and
unregistering stuff from that database is no longer necessary.

That does require an appropriate else clause in postrm files that use
ucf, and you should probably file bugs against those that don't, but
that's about it.

-- 
The biometric identification system at the gates of the CIA headquarters
works because there's a guard with a large gun making sure no one is
trying to fool the system.
  http://www.schneier.com/blog/archives/2009/01/biometrics.html


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Has Debian abandoned Python?

[Josselin Mouette]

Le dimanche 06 décembre 2009 à 22:47 -0800, Steve Langasek a écrit : 
> Python in Debian is currently in bad shape; on this, there is no
> disagreement whatsoever.  But it's in bad shape by the measure that *it's
> not meeting the needs of our users*, not because of where it stands relative
> to Ubuntu.

Indeed, the problem is the Python maintainer, regardless of who he works
for. The fact that it is in a better shape in a distribution which is
close to Debian shows, however, that a better situation is possible. In
the current situation[1] it would only require an upload of python2.6
and one of python-defaults (provided that the last python-central NMU is
not, again, replaced by a broken MU).

But when the maintainer specifically happens to work for a company that
claims to contribute back to Debian, on the same things he works for in
Debian, you can’t blame people for pointing out these claims are
outright lies.

You want to use Debian’s code? Fine, it’s free software. You don’t want
your employees to contribute? Fine too, no one is forced to work on
Debian. But if you brag about your lies, prepare to get bitten.

[1] 
http://bugs.debian.org/cgi-bin/pkgreport.cgi?users=debian-pyt...@lists.debian.org;tag=python2.6

-- 
 .''`.  Josselin Mouette
: :' :
`. `'   “I recommend you to learn English in hope that you in
  `- future understand things”  -- Jörg Schilling


signature.asc
Description: Ceci est une partie de message numériquement signée

Re: Bug#559774: ITP: modem-cmd -- send arbitrary AT commands to your modem

[Josselin Mouette]

Le lundi 07 décembre 2009 à 01:43 +0100, Robert Millan a écrit : 
> modem-cmd can be used to send arbitrary AT commands to a modem device
>  over a serial line.
>  .
>  For example:
>  .
>  $ modem-cmd /dev/ttyUSB0 ATDT123456

I don’t really see the point in packaging a 10-line shell script.

OTOH packaging vmcp[1] could be more useful, since it can also send
files, e.g. to control voice modems.

[1] http://www.unix.gr/gsm/voice/vmcp.c

-- 
 .''`.  Josselin Mouette
: :' :
`. `'   “I recommend you to learn English in hope that you in
  `- future understand things”  -- Jörg Schilling


signature.asc
Description: Ceci est une partie de message numériquement signée

Re: DEP-5: removed files

[Steve Langasek]

Hi Thibaut,

On Wed, Dec 02, 2009 at 03:56:51PM +0100, Thibaut Paumard wrote:

> I remember that debian/copyright should not only list where the
> source was downloaded from, but also the files which were removed by
> the packager and the motivation for the removal (DFSG, patents,
> large convenience copy of a library...). At least, that's how I
> interpret this (from [1], I cannot find an excerpt from policy):

> "3) Include a description of how you obtained the upstream source
> tarball. This should be sufficient for anybody to duplicate the
> process immediately, but don't worry too much if it isn't (eg, the
> server is not public or no longer accessible)."

This is not a requirement of Debian Policy; there are two other ways that
Policy already recommends communicating this information:

 - in the debian/README.source file
 - by way of a get-orig-source target in debian/rules

Providing the same information in debian/copyright would be redundant, and
should be avoided.

> I see no way with the current [2]DEP-5 proposal to store this
> information.

> My proposal would be to add a new type of sections:

> Removed-Files: similar to Files, for removed files
> Rationale: reason for the removal.

Given that Policy says to put this elsewhere than debian/copyright, I don't
think it makes sense for DEP-5 to specify such sections; this is probably
better addressed by including support for free-form comments, as suggested
elsewhere.

Cheers,
-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: Digital signature

Re: Should ucf be of priority required?

[Patrick Schoenfeld]

On Mon, Dec 07, 2009 at 09:08:08AM +0100, Raphael Hertzog wrote:
> So one day ucf might be deprecated by dpkg itself.

That day will be a good day. Thanks for the news.

Regards,
Patrick


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Should ucf be of priority required?

[Patrick Schoenfeld]

On Sun, Dec 06, 2009 at 11:47:11PM -0600, Manoj Srivastava wrote:
> >> In this particular case, what is the harm befalling the user?
> >
> > Well, I don't think that making an Operating System is just about
> > keeping harm away from our users.
> 
> But it is a tenet of software design that to change something
>  that is working,  you have to have some justification beyond I wish
>  things were different.

Making the software better, in this case. But this is quiet abstract in
this case, because this is not changing the design of a specific
tool, its about making the tool *always* perform its duties.

> I, on the other hand, _know_ you are not getting it.

Oh, fine. Leads us to a new level on our discussion. 

> > All I'm talking about is: The package that is beeing purged created data
> > during its installation. If it is beeing purged, it should remove this
> > data unless there is a good reason to keep it.
> 
> No it did not.  The data is all internal to ucf, the package has
>  no idea what the data  is -- and ucf can change  it internally  in any
>  way it wants, and the package will not be able to do anything about it.
> 
> You see, this is called, CS, abstraction.
> 
> The package calls ucf, and sends it a message. ucf does
>  something about it.

Right. Which is a perfectly fine form of abstraction.
 
> > In this case there is not even almost a reason to keep the data.
> 
> The package that calls ucf does not get to decide this.

No, thats wrong. The package that calls ucf does already decide this,
in the moment it gets purged and calls out to ucf to let it remove
this data, because its not used anymore. The usual case if ucf is
installed.

> > It has no use on a fresh installation of the package (and in fact it
> > must not, because the package has been purged). It has no use without
> > reinstalling the package (contrary to logfiles for example).
> > Basically its garbage.
> 
> Not your call to make. 

Well, its a fact. ucf does not need this data, the package does not need
that data. Not even the administrator needs that data.

> If ucf does something wrong with it,
>  point it out, and file a bug.

I never said that ucf does something wrong. I said that it does not
have the chance to do its duties.

> > So under this aspect I do not see how you can argue that I would need
> > to make a case why this should not happen. Shouldn't it be the other
> > way round? Shouldn't we make a case why we should or can leave
> > *garbage* on the users system when *purging* the package who created
> > that garbage?
> 
> Internal state information of icf is not garbage. It is not

Right. Its not garbage as long as it is a state information. It isn't
anymore when the package which created it, is purged, because there
is nothing ucf has to act on anymore.

> > Just to rememember:
> > purge  The package is selected to be purged (i.e. we want to remove
> >everything, even configuration files).
> 
> Bingo. These files do not belong to the package. They belong to
>  ucf. Why is that so hard to understand?

Ah, so we get to the point that you've never spoken out but wanted to
make me understand. Now I know, why you think that you know that I
haven't gotten it.

Well, in this point we simply disagree. The data in question is not
needed by ucf at this point. In fact ucf would never have needed this
data, if the package wasn't installed in the first place. And even since
it has been installed the data has more relevance to the package itself,
because ucf is just a tool to aid the maintainer scripts in getting a
job done.

And the fact that purging a package, which uses ucf, usually would
remove the data from the ucf registry as well weakens your point.
If it would belong to ucf why bother with removing it at all?

> I think you are very mistaken.

I could say the same from you. Thats how it is, if opinions differ.
But I come to the conclusion that its not worth discussing it anymore.
Its a minimal issue and we will not reach a consense. Other people are not
involved in the discussion anymore, so EOD for me.

Regards,
Patrick


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Should ucf be of priority required?

[sean finney]

hiya,

On Sun, Dec 06, 2009 at 07:36:18PM -0800, Steve Langasek wrote:
> I think there's ongoing work to support debconf prompting for conffiles, but
> I don't think there's movement on integrating ucf functionality into dpkg.
> ICBW, though.

there was some work at some point on integrating debconf into dpkg but
i don't think anyone's worked on pushing it in a long time.  however,
there is stuff in the pipes for basic ucf-like functionality[1].


sean

[1] tracking of dist versions of conffiles and merging, not dynamic
registration though.


signature.asc
Description: Digital signature

Re: Should ucf be of priority required?

[Raphael Hertzog]

On Sun, 06 Dec 2009, Steve Langasek wrote:
> I think there's ongoing work to support debconf prompting for conffiles, but
> I don't think there's movement on integrating ucf functionality into dpkg.
> ICBW, though.

I don't expect progress soon but it's on dpkg's roadmap:
http://wiki.debian.org/Teams/Dpkg/RoadMap

So one day ucf might be deprecated by dpkg itself.

Cheers,
-- 
Raphaël Hertzog


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Has Debian abandoned Python?

[Frans Pop]

On Monday 07 December 2009, Frans Pop wrote:
> But when you have a core package maintained by one and the same person,
> I do think that that person has a moral obligation to maintain his
> package as well and as timely for Debian as he does for Ubuntu.

And has an obligation to discuss major changes in the packaging within 
Debian before implementing them.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Bug#559761: ITP: release -- provides information about the current releases

[Frank Lin PIAT]

On Mon, 2009-12-07 at 00:14 +0100, Benjamin Drung wrote:
> 
> * Package name: release

The tool isn't about releasing, but about to querying the release. Also,
it's about distribution release (not package...). May be a name like
{get|query}-distr[o]?-release... or something completely different like
"supported-distro" would be more explicit.

>   Description : provides information about the current releases
> 
>  This package contains information about all releases of Debian and Ubuntu. 
> The
>  release script will give you the codename for e.g. the latest stable release 
> of
>  your distribution.

There was some discussions about a similar tool & issues:
 http://lists.debian.org/debian-devel/2007/05/msg01138.html
and to query Debian point release.
 http://lists.debian.org/debian-devel/2007/12/msg00742.html

>  To get information about a specific distribution there are
>  the debian-release and the ubuntu-release scripts.

I suppose you mean that there will be different back-end script.
(I suppose that you don't mean that each program will have to implement
a select/case algorithm?)

> It's based on the idea posted on the ubuntu-devel-discuss mailing list
> [1]. Comments, suggestions and feature requests are highly welcome.
> 
> For Debian I need some informations: Until when were following
> releases supported: buzz, rex, bo, hamm, slink, and potato?

See http://wiki.debian.org/DebianReleases but I didn't/couldn't find the
information for bo/rex/buzz. Anyone ?

AFAIK, Debian have never supported more than two stable distributions
(stable + old-stable), therefore, you can assume that a distribution end
of life is "lower than" distribution N+2 release.

Franklin


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Has Debian abandoned Python?

[Frans Pop]

Steve Langasek wrote:
> No, because it's no longer an objective measure of whether the
> maintenance of the package is adequate.  Your definition of "adequate"
> maintenance is now based on how Debian is doing *compared to* Ubuntu,
> which is not a standard that would be used anywhere else!

You are skewing my arguments in a way that I find distasteful.

The basic point in my mails was that there is a maintainer who is 
responsible for Python in both Debian and Ubuntu, and while the Ubuntu 
packaging has made progress, the Debian packaging *over a substantial 
period of time* has not while that maintainer has also not participated on 
the debian-python mailing list.

The conclusion in the first mail was that that maintainer is apparently no 
longer sufficiently motivated to perform his responsibilities as the 
maintainer of a core package in Debian.

The reasons are secondary, but IMO there definitely is a pattern that when 
DDs get employed by Canonical they get so swamped with Ubuntu work that 
Debian gets pushed to the background.
I've also said that I have no problem with that - people do lose motivation 
or simply don't have the spare time anymore for any number of reasons.

But I do feel that someone in that specific position should do the right 
thing and step down as lead maintainer for the Debian package which would 
immediately free him to do whatever he wants for Ubuntu (although 
collaboration with the Debian Python maintainers would of course still be 
a very good thing). It would also break the current deadlock for Debian by 
enabling others within Debian to step in and push Python forward for 
Debian.

I have no problem with Ubuntu being ahead for shortish periods of time on 
anything. And when there are *different maintainers* of a package for the 
two distributions there is no hard obligation for Ubuntu to actively push 
back to Debian.
But when you have a core package maintained by one and the same person, I 
do think that that person has a moral obligation to maintain his package 
as well and as timely for Debian as he does for Ubuntu.

Given all the loud noise made by Canonical about collaboration and giving 
back, I also think that Canonical (more than any other random employer) 
has a responsibility to actively avoid leaving Debian in the kind of 
deadlock we currently have for Python.

> If you don't believe this is true, then why are we having this
> discussion about python, and not about:

Because those are utterly different cases.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org