Re: postinst scripts failing because a new conffile wasn't accepted: Is it a bug?

[Olaf van der Spek]

On 11/1/05, Frank Lichtenheld <[EMAIL PROTECTED]> wrote:
> On Mon, Oct 31, 2005 at 06:56:44PM +0100, Frank Küster wrote:
> > In my opinion this is not a bug (except if the package is crucial for
> > the system to work and be reachable, like ssh) - the local admin simply
> > has to review the changes to conffiles that dpkg requested, and have a
> > look at NEWS.Debian and changelog.Debian.  If these files do not contain
> > enough information to fix the system, then this is a bug, right?  But
> > the simple fact that a postinst script fails because a change has been
> > refused isn't - and for sure it is not a serious or grave bug,
> > severities often used when a postinst fails.
> >
> > Opinions?
>
> There is one big problem with that scenario that I haven't seen
> mentioned in this thread yet: If I make the dist-upgrade of a machine
> from sarge to etch and the dist-upgrade fails right in the middle
> of the installed 3000 packages I will be severly disappointed to
> say the least if that didn't happen for a very good reason...
> That's a fact that often gets lost when discussing such problem from
> developer to developer that install sid on their machines and update
> about 30 packages at once.
>
> So if it is at all possible to avoid failing the postinst (which of
> course also means to not break other packages installation as you
> have pointed out) it should be done.

Wouldn't it be better to improve apt so it doesn't abort if a single
package fails?
It should still be able to continue with independent packages.

Re: Help: Bug#336469: pure-ftpd uninstallable : no pure-ftpd-common

[Henning Makholm]

Scripsit Steve Langasek <[EMAIL PROTECTED]>

> No, it's a bug in dpkg-dev, which should know how to set ${Source-Version}
> correctly for binNMUs.

It can't really know, can it? If I have a control file with

  Package: foo
  Architecture: any

  Package: foo-data-extra
  Architecture: all

  Package: foo-plugins
  Architecture: any
  Depends: foo (=${Source-Version}), foo-data-extra (=${Source-Version})

then a binNMU ought to have foo-plugins depend on the binNMU'ed
version of foo, but on the common version of foo-data-extra.
If dpkg-gencontrol were to figure out that, it would need to parse a
lot of data that it currently doesn't. And even if it did it
correctly, the resulting behavior would be confusing.

IMO it would be better to split ${Source-Version} into two substvars,
one of which includes binNMU suffixes and one of which doesn't.

-- 
Henning Makholm "In my opinion, this child don't
   need to have his head shrunk at all."


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Transition time: KDE, JACK, arts, sablotron, unixodbc, net-snmp, php, ...

[Henning Makholm]

Scripsit Josh Metzler <[EMAIL PROTECTED]>
> On Monday 31 October 2005 09:54 am, Henning Makholm wrote:

>> This confuses me a bit; I thought that 'autotrace' was in the mess too
>> (due to libmagick and libpstoedit transitions), and had an upload to
>> make it installable-in-sid planned for tonight, now that pstoedit has
>> been fixed again. However, autotrace appears on neither of your lists.

> http://packages.qa.debian.org/autotrace indicates that autotrace is not in 
> testing right now, so supposedly it was already removed.

Interesting. I don't think anybody will miss autotrace in testing for
the time being (it exists mostly because it's a build-dependency of
something), but it would be nice if the maintainter was informed when
a package gets removed from testing.

-- 
Henning Makholm   "Man vælger jo selv sine forbilleder."

Re: Best practices on system users and groups

[Lars Wirzenius]

ma, 2005-10-31 kello 22:03 +0100, Javier Fernández-Sanguino Peña
kirjoitti:
> After the feedback of the recent d-d thread, I've adapted the section I wrote
> on the best practices related to system users and groups, it is currently
> available at:
> http://www.debian.org/doc/manuals/developers-reference/ch-best-pkging-practices.en.html#s-bpp-lower-privs
> 
> I would like developers to review and provide feedback for that section,
> specially in form of patches. I'm considering doing a bug hunt for:

DON'T do this:

addgroup --quiet --system $SERVER_GROUP 2>/dev/null ||true

When (not if!) addgroup fails, the poor system administrator gets no
indication of it. This is a bug, and a pretty bad one. 

If adduser isn't quiet enough with --quiet, then fix that, don't hide
real errors. Remove both the redirect and the "|| true".

Also, sticking all the tens of lines of boilerplate code into the
postinst of every package that needs a system user is a good way to
invite trouble. When the boilerplate has a bug (possibly because things
change in the future), it will have to be fixed in dozes on of packages.
It's oh so much more sensible to create a tool that postinsts can call:
if boilerplate code is good enough, then it can easily be abstracted
away.

-- 
Fundamental truth #1: Complexity is the enemy.

Re: postinst scripts failing because a new conffile wasn't accepted: Is it a bug?

[Frank Küster]

Frank Lichtenheld <[EMAIL PROTECTED]> wrote:

> On Mon, Oct 31, 2005 at 06:56:44PM +0100, Frank Küster wrote:
>> In my opinion this is not a bug (except if the package is crucial for
>> the system to work and be reachable, like ssh) - the local admin simply
>> has to review the changes to conffiles that dpkg requested, and have a
>> look at NEWS.Debian and changelog.Debian.  If these files do not contain
>> enough information to fix the system, then this is a bug, right?  But
>> the simple fact that a postinst script fails because a change has been
>> refused isn't - and for sure it is not a serious or grave bug,
>> severities often used when a postinst fails.
>> 
>> Opinions?
>
> There is one big problem with that scenario that I haven't seen
> mentioned in this thread yet: If I make the dist-upgrade of a machine
> from sarge to etch and the dist-upgrade fails right in the middle
> of the installed 3000 packages I will be severly disappointed to
> say the least if that didn't happen for a very good reason...
> That's a fact that often gets lost when discussing such problem from
> developer to developer that install sid on their machines and update
> about 30 packages at once.

Maybe we need a policy (or a change in dpkg's default behavior) for
that.  One option would be to recommend to take the new version and
merge local changes afterwards (but this might severely break more
important things, like ssh in an environment where port 22 is
blocked...).  Or on the other hand, packages that change incompatibly
must ensure that they are not installed automatically - however that
would mean that every package that build-depends on the changed package
would have to change its control file.

> So if it is at all possible to avoid failing the postinst (which of
> course also means to not break other packages installation as you
> have pointed out) it should be done.
>
> If it is at all possible in the case of tetex I can't tell, though.

I do not see how it could be made possible.  Oh, yes, there is one way,
and we have even tried to go that route:  After the conffile questions
have been asked, we check in the postinst script whether some essential
entries in ucf-managed configuration files are wrong, and if they are we
change the file.  But we can't do that for dpkg-managed files, and in
any case I don't want to have a 1000 line postinst script because it
checks for 30 possibly fatal refused changes...

Regards, Frank
-- 
Frank Küster
Inst. f. Biochemie der Univ. Zürich
Debian Developer

Re: postinst scripts failing because a new conffile wasn't accepted: Is it a bug?

[Henning Makholm]

Scripsit Frank Küster <[EMAIL PROTECTED]>

> These variables can be changed by a configuration file, and some of them
> *must* be set.  Now if a user refuses to accept the change that switches
> from VARTEXMF to TEXMFVAR (or TEXMFSYSVAR, actually), TeX can no longer
> work.

You seem to assume that the *only* way to get this change into the
file is to forcibly discard all of the sysadmin's local adaptations
and install a pristine upstream version of the conffile.

Why do you want to deny the sysadmin the opportunity to do the changes
himself?

He presumably did have a good reason to make the local adaptations he
did, and who are you do decree that his preferred method of solution
MUST be to redo all of his local adaptations by hand, instead of to
make the simple upstream change to one line in the file by hand?

-- 
Henning Makholm  "It will be useful even at this
  early stage to review briefly the main
  features of the universe as they are known today."

Re: Transition time: KDE, JACK, arts, sablotron, unixodbc, net-snmp, php, ...

[Steve Langasek]

On Tue, Nov 01, 2005 at 09:29:58AM +0100, Henning Makholm wrote:
> Scripsit Josh Metzler <[EMAIL PROTECTED]>
> > On Monday 31 October 2005 09:54 am, Henning Makholm wrote:

> >> This confuses me a bit; I thought that 'autotrace' was in the mess too
> >> (due to libmagick and libpstoedit transitions), and had an upload to
> >> make it installable-in-sid planned for tonight, now that pstoedit has
> >> been fixed again. However, autotrace appears on neither of your lists.

> > http://packages.qa.debian.org/autotrace indicates that autotrace is not in 
> > testing right now, so supposedly it was already removed.

> Interesting. I don't think anybody will miss autotrace in testing for
> the time being (it exists mostly because it's a build-dependency of
> something), but it would be nice if the maintainter was informed when
> a package gets removed from testing.

This is a reasonable concern, but the standing policy is that if a package
is RC-buggy, it's a candidate for removal from testing at any time.  We
would like to get notices to maintainers set up, but in the majority of
cases the presence of an RC bug on the package is already ample notice.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
[EMAIL PROTECTED]   http://www.debian.org/


signature.asc
Description: Digital signature

Re: Transition time: KDE, JACK, arts, sablotron, unixodbc, net-snmp, php, ...

[Frank Küster]

Henning Makholm <[EMAIL PROTECTED]> wrote:

> Scripsit Josh Metzler <[EMAIL PROTECTED]>
>> On Monday 31 October 2005 09:54 am, Henning Makholm wrote:
>
>>> This confuses me a bit; I thought that 'autotrace' was in the mess too
>>> (due to libmagick and libpstoedit transitions), and had an upload to
>>> make it installable-in-sid planned for tonight, now that pstoedit has
>>> been fixed again. However, autotrace appears on neither of your lists.
>
>> http://packages.qa.debian.org/autotrace indicates that autotrace is not in 
>> testing right now, so supposedly it was already removed.
>
> Interesting. I don't think anybody will miss autotrace in testing for
> the time being (it exists mostly because it's a build-dependency of
> something), but it would be nice if the maintainter was informed when
> a package gets removed from testing.

... and if the maintainer had some place where they could look up the
rationale.

Regards, Frank
-- 
Frank Küster
Inst. f. Biochemie der Univ. Zürich
Debian Developer

Re: Help: Bug#336469: pure-ftpd uninstallable : no pure-ftpd-common

[Steve Langasek]

On Tue, Nov 01, 2005 at 09:27:06AM +0100, Henning Makholm wrote:
> Scripsit Steve Langasek <[EMAIL PROTECTED]>

> > No, it's a bug in dpkg-dev, which should know how to set ${Source-Version}
> > correctly for binNMUs.

> It can't really know, can it? If I have a control file with

>   Package: foo
>   Architecture: any

>   Package: foo-data-extra
>   Architecture: all

>   Package: foo-plugins
>   Architecture: any
>   Depends: foo (=${Source-Version}), foo-data-extra (=${Source-Version})

> then a binNMU ought to have foo-plugins depend on the binNMU'ed
> version of foo, but on the common version of foo-data-extra.
> If dpkg-gencontrol were to figure out that, it would need to parse a
> lot of data that it currently doesn't. And even if it did it
> correctly, the resulting behavior would be confusing.

> IMO it would be better to split ${Source-Version} into two substvars,
> one of which includes binNMU suffixes and one of which doesn't.

Yes; sorry, I thought it was self-evident that Source-Version ought to refer
to the *source* version, and that a new variable name is called for where
the binary version is needed.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
[EMAIL PROTECTED]   http://www.debian.org/


signature.asc
Description: Digital signature

Re: Best practices on system users and groups

[sean finney]

hi javier,

On Mon, Oct 31, 2005 at 10:03:01PM +0100, Javier Fernández-Sanguino Peña wrote:
> I would like developers to review and provide feedback for that section,

thanks for actually putting this into a document, however, i notice
two problems:

- the addgroup/adduser functions mask the error status, yet do not
  later check to see if the group was actually created.   this is doubly
  bad, because not only will the package continue to install, but no
  error message or warning is even printed.  here's a patch for adding a group:

--- foo 2005-11-01 10:29:15.0 +0100
+++ bar 2005-11-01 10:32:27.0 +0100
@@ -28,8 +28,13 @@
 # 1. create group if not existing
 if ! getent group | grep -q "^$SERVER_GROUP:" ; then
   echo -n "Adding group $SERVER_GROUP.."
-  addgroup --quiet --system $SERVER_GROUP 2>/dev/null ||true
- echo "..done"
+  addgroup --quiet --system $SERVER_GROUP ||true
+  if ! getent group | grep -q "^$SERVER_GROUP:"; then
+  echo "...error encountered"
+  exit 1
+  else
+  echo "...done"
+  fi
 fi

  ... and the same for adding users.


  the second thing i notice is that you arbitrarily modify the user in
  question via usermod, which would override the local admin's changes.
  i wonder whether it is even good to recommend this at all.

On Tue, Nov 01, 2005 at 11:14:59AM +0200, Lars Wirzenius wrote:
> Also, sticking all the tens of lines of boilerplate code into the
> postinst of every package that needs a system user is a good way to
> invite trouble. When the boilerplate has a bug (possibly because things
> change in the future), it will have to be fixed in dozes on of packages.
> It's oh so much more sensible to create a tool that postinsts can call:
> if boilerplate code is good enough, then it can easily be abstracted
> away.

i'd like to double-ack this remark.  even if the oft-mentioned "dh_user"
were implemented, if there were a bug in this implementation, every
affected package would have to be /rebuilt/ if the buggy code were
actually in the postinsts.

if you're going to do this, it would be better to provide a program
or a shell library that is sourced in the postinst, and then
awrapper function which does all of this.  


sean

-- 


signature.asc
Description: Digital signature

Re: Packages file missing from unstable archive

[Anthony Towns]

On Sun, Oct 30, 2005 at 09:48:35AM +0100, Goswin von Brederlow wrote:
> Zsync checksum files are, depending on block size, about 3% of the
> file size. For the full archive that means under 10G more data. As
> comparison adding amd64 needs ~30G. After the scc split there might be
> enough space on mirrors for both.

Adding amd64 needs 30G? Since when?

And stuff doesn't go on the mirrors because it's "under 30G", it goes on
the mirrors because it provides useful benefits. Where're the statistics
showing how much zsync signatures actually help?

Cheers,
aj


signature.asc
Description: Digital signature

Re: Best practices on system users and groups

[Olaf van der Spek]

ma, 2005-10-31 kello 22:03 +0100, Javier Fernández-Sanguino Peña
kirjoitti:
> I would like developers to review and provide feedback for that section,
> specially in form of patches. I'm considering doing a bug hunt for:

> Typically this means that the configuration files are owned by group, belong 
> to the group of the system user and are mode 0640.

Owned by group? What group?

> If the daemon logs to a directory under /var/log/ then *it* should be owned 
> by the system user and rotated log files need not be changed ownership.

What does *it* mean? The directory or the log file?

Re: Transition time: KDE, JACK, arts, sablotron, unixodbc, net-snmp, php, ...

[Henning Makholm]

Scripsit Steve Langasek <[EMAIL PROTECTED]>
> On Tue, Nov 01, 2005 at 09:29:58AM +0100, Henning Makholm wrote:

>> Interesting. I don't think anybody will miss autotrace in testing for
>> the time being (it exists mostly because it's a build-dependency of
>> something), but it would be nice if the maintainter was informed when
>> a package gets removed from testing.

> This is a reasonable concern, but the standing policy is that if a package
> is RC-buggy, it's a candidate for removal from testing at any time.

The fact that "it is a candidate for removal" is a completely
different state from "it _has_ been removed". I don't see how you can
suppose that the difference is not important for maintainers.

Also, the only RC bugginess that has applied to autotrace in recent
memory is that it was uninstallable in sid due to library transitions,
and not uploadable because its build-dependencies were not in order
yet (which was duly noted in the bug reports).  I do not think this
falls under a "maintainer himself ignores his bugs and therefore
deserves to be left in the dark" heading.

Well, the build-dependencies became fixed about 4 days ago (courtesy
of a NMU by yours truly). Is 4 days enough to get something removed
from testing?

> We would like to get notices to maintainers set up, but in the
> majority of cases the presence of an RC bug on the package is
> already ample notice.

No it's not.

   RC bug, still in testing -> fixing this is very important, because
   it may hold up the testing migration of other packages.

   RC bug, not in testing -> fixing this only affects this one
   package, and is therefore not so urgent.

The removal from testing drastically changes which priorities I should
use in allocating the time I can use for Debian stuff.

-- 
Henning Makholm "I've been staying out of family
   conversations. Do I get credit for that?"


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: postinst scripts failing because a new conffile wasn't accepted: Is it a bug?

[Frank Küster]

Henning Makholm <[EMAIL PROTECTED]> wrote:

> Scripsit Frank Küster <[EMAIL PROTECTED]>
>
>> These variables can be changed by a configuration file, and some of them
>> *must* be set.  Now if a user refuses to accept the change that switches
>> from VARTEXMF to TEXMFVAR (or TEXMFSYSVAR, actually), TeX can no longer
>> work.
>
> You seem to assume that the *only* way to get this change into the
> file is to forcibly discard all of the sysadmin's local adaptations
> and install a pristine upstream version of the conffile.

No, of course there is an other way:  dpkg offers an option to start a
shell (or put itself in the background or whatever) to clear up the
situation; or one can simply log in on a different terminal.  But if the
local admin doesn't want to do that, but delay merging the configuration
file, there are only two possibilities:  Either he accepts the new
maintainer's version, or he refuses it.  And the latter choice leads to
a failure of the postinst script in some cases.

It's only *some* cases; I think in the most important cases, the file
isn't dpkg-managed (but ucf-managed), anyway, so we choose to forcibly
introduce the variable name changes if the rest of the line was
unchanged (or "recognizable").  But that cannot always be done, and in
fact the reason why I decided to ask this is because a user had an old
version of a conffile of an other package.  The other package depends on
tetex, and must recreate its format ("reinitialize") when tetex is
updated - and made tetex's postinst fail.

> Why do you want to deny the sysadmin the opportunity to do the changes
> himself?

I don't.  All I do is request some support for the view that if he
decides to do so, he should in fact do it before filing a bug; and if he
files a bug that I can close or downgrade it to non-RC severity.

Regards, Frank
-- 
Frank Küster
Inst. f. Biochemie der Univ. Zürich
Debian Developer

Re: Best practices on system users and groups

[Jonas Meurer]

On 31/10/2005 Javier Fernández-Sanguino Peña wrote:
> After the feedback of the recent d-d thread, I've adapted the section I wrote
> on the best practices related to system users and groups, it is currently
> available at:
> http://www.debian.org/doc/manuals/developers-reference/ch-best-pkging-practices.en.html#s-bpp-lower-privs

the group deletion has currently a problem. From 6.5.1.3 'Removing system
users':

# Remove system group if is a system group
CREATEDGROUP=server_group
if [ -r /etc/adduser.conf ] ; then
  FIRST_USER_GID=`grep ^USERS_GID /etc/adduser.conf | cut -f2 -d '='`
else
  FIRST_USER_GID=1000
fi
if [ -n "$FIST_USER_GID" ] then
  if GROUPGID=`getent group $CREATEDGROUP | cut -f 3 -d ':'`; then
if [ -n "$GROUPGID" ]; then
  if [ "$FIST_USER_GID" -gt "$GROUPGID" ]; then
echo -n "Removing $CREATEDGROUP group.."
delgroup --only-if-empty $CREATEDGROUP || true
echo "..done"
  fi
fi
  fi
fi

first, the 'if [ -n "$FIST_USER_GID" ] then' should better be
'if [ -n "$FIRST_USER_GID"]; then' (two small typos).

second, and more important, the default GID for the group 'users' is 100
for adduser, so the check above will always fail. system groups created
via 'addgroup --system' have GIDs between 100 and 199.
in my eyes it would be more sane to check for FIRST_SYSTEM_GID instead
of USERS_GID.

...
 jonas


signature.asc
Description: Digital signature

Re: Best practices on system users and groups

[Jonas Meurer]

On 01/11/2005 To Debian-Devel wrote:
> the group deletion has currently a problem. From 6.5.1.3 'Removing system
> users':
> 
> # Remove system group if is a system group
> CREATEDGROUP=server_group
> if [ -r /etc/adduser.conf ] ; then
>   FIRST_USER_GID=`grep ^USERS_GID /etc/adduser.conf | cut -f2 -d '='`
> else
>   FIRST_USER_GID=1000
> fi
> if [ -n "$FIST_USER_GID" ] then
>   if GROUPGID=`getent group $CREATEDGROUP | cut -f 3 -d ':'`; then
> if [ -n "$GROUPGID" ]; then
>   if [ "$FIST_USER_GID" -gt "$GROUPGID" ]; then
> echo -n "Removing $CREATEDGROUP group.."
>   delgroup --only-if-empty $CREATEDGROUP || true
>   echo "..done"
>   fi
> fi
>   fi
> fi
> 
> second, and more important, the default GID for the group 'users' is 100
> for adduser, so the check above will always fail. system groups created
> via 'addgroup --system' have GIDs between 100 and 199.
> in my eyes it would be more sane to check for FIRST_SYSTEM_GID instead
> of USERS_GID.

sorry, i mean LAST_SYSTEM_GID. best would be:

FIRST_SYSTEM_GID=`grep ^FIRST_SYSTEM_GID /etc/adduser.conf | cut -f2 -d '='`
LAST_SYSTEM_GID=`grep ^LAST_SYSTEM_GID /etc/adduser.conf | cut -f2 -d '='`
[...]
if [ "$LAST_SYSTEM_GID" -gt "$GROUPGID" ] && [ "$FIRST_SYSTEM_GID" -lt 
"$GROUPGID" ]; then
  [...]
fi

...
 jonas


signature.asc
Description: Digital signature

Re: Transition time: KDE, JACK, arts, sablotron, unixodbc, net-snmp, php, ...

[Henning Makholm]

Scripsit Henning Makholm <[EMAIL PROTECTED]>
> Scripsit Steve Langasek <[EMAIL PROTECTED]>

>> This is a reasonable concern, but the standing policy is that if a package
>> is RC-buggy, it's a candidate for removal from testing at any time.

> The fact that "it is a candidate for removal" is a completely
> different state from "it _has_ been removed". I don't see how you can
> suppose that the difference is not important for maintainers.

Calm down, Henning ... view this as an opportunity to contribute
rather than a reason to complain.

So, would anybody object if I set up a cronjob that emails the PTS
whenever a (source) package propagates to, or is removed from, testing?

-- 
Henning Makholm   "I always thought being *real* sad
would be *cooler* than acting *fake*
 sad, but it's not. It's not cool at *all*."


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: postinst scripts failing because a new conffile wasn't accepted: Is it a bug?

[Henning Makholm]

Scripsit Frank Küster <[EMAIL PROTECTED]>
> Henning Makholm <[EMAIL PROTECTED]> wrote:

>> You seem to assume that the *only* way to get this change into the
>> file is to forcibly discard all of the sysadmin's local adaptations
>> and install a pristine upstream version of the conffile.

> No, of course there is an other way:  dpkg offers an option to start a
> shell (or put itself in the background or whatever) to clear up the
> situation; or one can simply log in on a different terminal.

Exactly, but what happens then is

  1. User backgrounds dpkg, or switches to another window.
  2. User edits the file to take into account the new variable name.
  3. User returns to dpkg.
  4. User selects the "No, I'm happy with my own version as it look
 now" menu option.

Your proposal, if I understand you correctly, is to make (4) result in
the postinst failing even though the user _has_ taken care of the problem.

> But if the local admin doesn't want to do that, but delay merging
> the configuration file, there are only two possibilities: Either he
> accepts the new maintainer's version, or he refuses it.  And the
> latter choice leads to a failure of the postinst script in some
> cases.

This is not true. If he edits the file himself (but refuses the
maintainer's version because accepting it would lead to his own
changes being overwritten) things still work fine.

>> Why do you want to deny the sysadmin the opportunity to do the changes
>> himself?

> I don't.

You want the postinst to fail if he does the changes himself rather
than abandoning all of his local changes, right? That is _not_ how
conffiles are supposed to work.

> All I do is request some support for the view that if he decides to
> do so, he should in fact do it before filing a bug;

Of course it is not a bug if the package fails because the admin does
not properly adjust his conffiles.

But it _is_ a bug if the postinst refuses to do its work unless it
gets to overwrite the conffile with a pristine upstream version.

-- 
Henning Makholm  "Wir kommen nun ans Ziel unserer Ausführungen."

Re: postinst scripts failing because a new conffile wasn't accepted: Is it a bug?

[Frank Küster]

Henning Makholm <[EMAIL PROTECTED]> wrote:

> Scripsit Frank Küster <[EMAIL PROTECTED]>
>> Henning Makholm <[EMAIL PROTECTED]> wrote:
>
>>> You seem to assume that the *only* way to get this change into the
>>> file is to forcibly discard all of the sysadmin's local adaptations
>>> and install a pristine upstream version of the conffile.
>
>> No, of course there is an other way:  dpkg offers an option to start a
>> shell (or put itself in the background or whatever) to clear up the
>> situation; or one can simply log in on a different terminal.
>
> Exactly, but what happens then is
>
>   1. User backgrounds dpkg, or switches to another window.
>   2. User edits the file to take into account the new variable name.
>   3. User returns to dpkg.
>   4. User selects the "No, I'm happy with my own version as it look
>  now" menu option.
>
> Your proposal, if I understand you correctly, is to make (4) result in
> the postinst failing even though the user _has_ taken care of the problem.

You must have misunderstood me.  I don't check whether the installed
file is the one I expect; I simply run "fmtutil --all" - and that will
fail if he hasn't solved the problem.

>> But if the local admin doesn't want to do that, but delay merging
>> the configuration file, there are only two possibilities: Either he
>> accepts the new maintainer's version, or he refuses it.  And the
>> latter choice leads to a failure of the postinst script in some
>> cases.
>
> This is not true. 

It is - with "that" I meant to edit the file now.

> If he edits the file himself (but refuses the
> maintainer's version because accepting it would lead to his own
> changes being overwritten) things still work fine.

Of course they will.  In particular, I won't get a bug report and won't
have to consider closing or downgrading it, and ask questions on -devel
:-) 

>>> Why do you want to deny the sysadmin the opportunity to do the changes
>>> himself?
>
>> I don't.
>
> You want the postinst to fail if he does the changes himself rather
> than abandoning all of his local changes, right?

No, if I have written something like this I must have been insane.  All
I want to say is:  If he does the changes himself bug does it wrong, the
fmtutil call (or updmap or whatever) in postinst will fail.  

But this is in fact a corner case, the usual situation is that the user
pressed "keep local version" without thinking, or simply uses the
noninteractive frontend and doesn't bother himself with looking at any
*.dpkg-new files before reporting the bug.

>> All I do is request some support for the view that if he decides to
>> do so, he should in fact do it before filing a bug;
>
> Of course it is not a bug if the package fails because the admin does
> not properly adjust his conffiles.

So finally there is one person who simply says "yes" to the question in
the first mail, thank you.  

By the way, I don't think that the answer should be a simple "yes": If a
failure to configure might cause the system to be inaccessible over the
net, the package maintainer has to take care to avoid this (i.e. ask a
non-debconfized question in preinst, as glibc does).

Regards, Frank

-- 
Frank Küster
Inst. f. Biochemie der Univ. Zürich
Debian Developer

Bug#336771: ITP: nymbaron -- type III nymserver - get and send emails anonymously

[Laurent Fousse]

Package: wnpp
Severity: wishlist
Owner: Laurent Fousse <[EMAIL PROTECTED]>

* Package name: nymbaron
  Version : 0.0.20050507
  Upstream Authors : Laurent Fousse <[EMAIL PROTECTED]>,
 Jean-René Reinhard <[EMAIL PROTECTED]>.
* URL : http://www.komite.net/laurent/soft/nymbaron
* License : MIT/X
  Description : type III nymserver - get and send emails anonymously

 A nymserver is a mail server which stores emails on behalf of
 anonymous users. It provides long-term pseudonymous identities which
 can receive and send emails through the server, without revealing the
 user controling those identities.
 .
 This nymserver is built upon the mixminion remailer network.
 .
 WARNING: this is still considered alpha quality software. Do NOT use
 it if you require strong anonymity.
 .
 This package contains client and server binaries.
 .
  Homepage: http://www.komite.net/laurent/soft/nym3/


signature.asc
Description: Digital signature

Re: postinst scripts failing because a new conffile wasn't accepted: Is it a bug?

[Petter Reinholdtsen]

[Frank Küster]
> assume that an update to a package brings in a changed conffile, and
> because the local admin had changed the conffile, he is asked, and he
> refuses to accept the changed version.
>
> Because one of the changes in the new version was crucial for the
> function of the program, the postinst script fails to initialize it, and
> the whole installation process fails.

My proposal to avoid such problem is to implement multilevel
configuration, where the package default configuration and the local
overrides are stored in separate files, making sure local
configuration do not affect changes to the package default, and thus
no question is asked during upgrade.

I talked a bit about this during debconf5.  Have a look at
http://meetings-archive.debian.net/pub/debian-meetings/2005/debconf5/mpeg/2005-07-12/06-Writing_Enterprise_Ready_Software-Petter_Reinholdtsen.mpeg>
and
http://meetings-archive.debian.net/pub/debian-meetings/2005/debconf5/mpeg/2005-07-16/12-Debian_Edu_Upgrading_a_Preconfigured_CDD-Petter_Reinholdtsen.mpeg>,
as well as the slides available from
http://wiki.debian.org/?DebConf5Talks>.

Moving tetex to such mechanism would require some work. :)


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Dummy packages and metapackages (call for consistency in the descriptions)

[Henrique de Moraes Holschuh]

On Mon, 31 Oct 2005, Andreas Tille wrote:
> The meta packages builded by cdd-dev for instance contain data for building
> user menus which might override the menu entries of the dependant packages
> for the special purpose.  This is definitely something else than
> debian/control but sounds to me definitely well placed in this kind of
> packages.  Moreover the package might contain extra documentation for
> the dependant packages which seems to be reasonable in the meta package
> context.

IMHO, drop the "Meta" prefix, then.  There is no shame in doing so.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Dummy packages and metapackages (call for consistency in the descriptions)

[Andreas Tille]

On Tue, 1 Nov 2005, Henrique de Moraes Holschuh wrote:


IMHO, drop the "Meta" prefix, then.  There is no shame in doing so.


Well, just dropping the meta is a little bit to simple.  There is an
extensive documentation about the Custom Debian Distribution techniques
and the tools that are used at

http://people.debian.org/~tille/cdd/

It makes IMHO no sense to invent just another prefix in front of "package"
instead of "meta" just because there might be some additional (optional)
information inside these packages which is not contained in debian/control,
but reasonably is called meta information for the relevant task.  It makes
no sense to play wording games just because there are some people who think
that the definition we gave on

http://people.debian.org/~tille/cdd/ch-technology.en.html#s-metapackages

does not fit into the scope they would give the name "meta package".

Kind regards

   Andreas.

--
http://fam-tille.de


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Are pure virtual Depends/Recommends entries bugs?

[Daniel Burrows]

  As I'm sure everyone knows, pure virtual entries in a Depends line are
strongly deprecated, due to the fact that frontends have a tendency to pick
a random provider of the package.  What I'm not sure is if this is just "ugly"
or actually considered a bug.  In particular, I can't remember and would like
to know:

  (a) Is a pure virtual entry with no prior alternative in a Depends line an
  actual bug?  i.e., do we have a consensus on this?

  (b) If the answer to (a) is "yes", is a pure virtual *Recommendation* a bug?

  Rationale: Recommendations are intended to be installed by default, so
  their fields should be just as friendly to automatic tools as Depends is.

  Daniel


signature.asc
Description: Digital signature

Re: Best practices on system users and groups

[Marc Haber]

On Tue, 1 Nov 2005 04:53:33 -0500, sean finney <[EMAIL PROTECTED]>
wrote:
>if you're going to do this, it would be better to provide a program
>or a shell library that is sourced in the postinst, and then
>awrapper function which does all of this.  

I would be willing to accept patches for the adduser package (either
for the adduser script itself or for additional scripts) to solve
this.

Greetings
Marc

-- 
-- !! No courtesy copies, please !! -
Marc Haber |   " Questions are the | Mailadresse im Header
Mannheim, Germany  | Beginning of Wisdom " | http://www.zugschlus.de/
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834

Re: Dummy packages and metapackages (call for consistency in the descriptions)

[Henrique de Moraes Holschuh]

On Tue, 01 Nov 2005, Andreas Tille wrote:
> does not fit into the scope they would give the name "meta package".

Well, I'd expect meta packages to have nothing on them and I'd be surprised
to find relevant data inside them.

If you have to keep that "meta", you'd better do some work on the package
descriptions to make sure they make it very clear that the package has data
inside it (other than packaging metadata, that is).  This avoids bad
surprises for others like me, that are used to meta-packages being packages
of packaging system metadata only.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Transition control

[Eduard Bloch]

#include 
* Simon Richter [Mon, Oct 31 2005, 07:00:43PM]:
> Hi,
> 
> Eduard Bloch schrieb:
> 
> > Yep. What about another crazy idea... why not check the expected impact
> > from a certain package update before a package has been accepted in
> > _Unstable_? So katie could just veto a version change automaticaly
> > before it too much mess is created, even (or especially) in Unstable. 
> 
> How about doing that via the autobuilders and experimental? I've been
> thinking about it for some time, and my proposal would be (indentation

No, it is not the same thing. What you propose is simply declaring
Experimental as playground for transitions, with some mechanisms to
detect/guess possibly expected transitions and automate them. However I
cannot see how it is supposed to solve the underlying problems.
Basically it is the same method just splitted into the "brave unstable"
and the "transition merge area" in Experimental which OTOH makes the
real (integration) testing more complicated. It also gives Experimental
a new purpose, conflicting with the current one, so this "transition
playground" needs to be a separate branch.

What I suggested is forcing more sanity on the side of maintainers, a
simple mechanisms which forces the critical things to be thought trough
twice. That would be a solution between the two extremes:

 - all power to one package maintainer (current situation)
 - comaintainers requirement for every package (discussed here a while
   ago, that looked good at the first glance but would not be effective
   enough and create overhead at wrong places)

Eduard.

-- 
Zathras: Zathras is used to being beast of burden to other people's needs. Very
sad life... probably have very sad death, but at least there is symmetry.
 -- B5 --


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Packages file missing from unstable archive

[Michael Vogt]

On Thu, Oct 27, 2005 at 10:06:22AM +0200, Robert Lemmen wrote:
> On Wed, Oct 26, 2005 at 09:15:38PM -0400, Joey Hess wrote:
> > (And yes, we still need a solution to speed up the actual deb file
> > downloads..)
[..]
> if zsync would be taught to handle .deb files as it does .gz files, and
> a method for apt be written, how big are the chances that support could 
> be integrated into dak? the effort wouldn't be *that* big...

I did a pretty unscientific test with apt and the changes from 
0.6.41 -> 0.6.42.1. It contains a good mix of code changes,
documentation updates and translation updates [1].

With the two normals debs I got no effect at all because no usable
data was found. 

I then repacked the data.tar.gz and control.tar.gz inside the deb with
"--rsyncable" (and reassmbled the deb).  This resulted in:
"Read apt_0.6.41_i386.deb. Target 0.8% complete."
So this didn't had a lot of effect either. 

My next test was to use only the data.tar.gz of the two
archives. Zsync will extract the gzip file then and use the tar as the
base. With that I got:
8<
Read data.tar.gz. Target 34.1% complete.
used 1056768 local, fetched 938415
8<
The size of the data.tar.gz is 1210514. 

A problem is that zsync needs to teached to deal with deb files (that
is, that it needs to unpack the data.tar and use that for the syncs).

Having it inside dak is not (at the beging) a requirement. Zsync seems
to be able to deal with URLs, so we could create a pool with zsync
files on any server and let them point to ftp.debian.org.

We need to guarantee that the md5sum of the synced deb must match the
md5sum in the Packages file. Initial tests indicate that that is not
the case. Only the md5sum of the unpacked data.tar file matches, not
from the gzip file (or the deb). This is a serious showstoper IMHO. 


Cheers,
 Michael

[1] I would love to hear results from other people testing it with
different packages and different changes.
-- 
Linux is not The Answer. Yes is the answer. Linux is The Question. - Neo


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: postinst scripts failing because a new conffile wasn't accepted: Is it a bug?

[Henning Makholm]

Scripsit Frank Küster <[EMAIL PROTECTED]>
> Henning Makholm <[EMAIL PROTECTED]> wrote:

>>   4. User selects the "No, I'm happy with my own version as it look
>>  now" menu option.

>> Your proposal, if I understand you correctly, is to make (4) result in
>> the postinst failing even though the user _has_ taken care of the problem.

> You must have misunderstood me.  I don't check whether the installed
> file is the one I expect; I simply run "fmtutil --all" - and that will
> fail if he hasn't solved the problem.

Ah. I read your proposal as if you wanted to somehow intercept the
user's answer and explicitly bail out from the postinst if the user
"is asked, and he refuses to accept the changed version".

>> Of course it is not a bug if the package fails because the admin does
>> not properly adjust his conffiles.

> So finally there is one person who simply says "yes" to the question in
> the first mail, thank you.  

> By the way, I don't think that the answer should be a simple "yes": If a
> failure to configure might cause the system to be inaccessible over the
> net, the package maintainer has to take care to avoid this (i.e. ask a
> non-debconfized question in preinst, as glibc does).

Generally, I think that we depend on the user who has chosen to change
a conffile himself to also be able to judge correctly whether a
maintainer-supplied change is relevant to him or not. Though this
assumption is often wrong, it is the best thing we have in general.
It is of course reasonable to be more paranoid than that in situations
where failure can impair one's ability to fix things later.

In the long run, the user-friendly solution is probably to offer (via
a debconf question that defaults to 'yes') to automatically rewrite
the conffile to take the change into account. In the case you're
presenting here it seems that it ought to be doable by
search-and-replace. The offer should only be made if the conffile has
actually changed *and* it mentions the old variable names *and* one is
upgrading from an older version.

-- 
Henning Makholm"We can hope that this serious deficiency will be
  remedied in the final version of BibTeX, 1.0, which is
expected to appear when the LaTeX 3.0 development is completed."

Re: Transition time: KDE, JACK, arts, sablotron, unixodbc, net-snmp, php, ...

[Anthony Towns]

On Tue, Nov 01, 2005 at 12:41:09PM +0100, Henning Makholm wrote:
> So, would anybody object if I set up a cronjob that emails the PTS
> whenever a (source) package propagates to, or is removed from, testing?

I won't so nobody'd object; but it's one of the things we agreed we
wanted at the Vancouver meeting. I think there was going to be a
-testing-changes list or something, perhaps? I forget exactly.

Cheers,
aj



signature.asc
Description: Digital signature

Re: Transition time: KDE, JACK, arts, sablotron, unixodbc, net-snmp, php, ...

[Anthony Towns]

On Tue, Nov 01, 2005 at 11:00:46AM +0100, Henning Makholm wrote:
> No it's not.
> 
>RC bug, still in testing -> fixing this is very important, because
>it may hold up the testing migration of other packages.
> 
>RC bug, not in testing -> fixing this only affects this one
>package, and is therefore not so urgent.

If the package isn't in testing, anything that depends on it isn't either,
so you can still be affecting more than one package. 

Also, the above talks about its effect on other maintainers; you might
also consider the effect on (potential) users of your package: in the
former case "fixing this isn't that important, because users can just
use the version in testing", while the latter is "fixing this is very
important, because users don't have any recent version to use".

Personally, I'd go for "RC bug -> fixing this is very important and
urgent", and end there, though.

Maybe it helps to look at it this way: testing tries to match unstable,
while filtering out the crap; the more crap there is in unstable the
harder that is and the more likely it is the filter will get clogged.

Cheers,
aj



signature.asc
Description: Digital signature

Re: Transition time: KDE, JACK, arts, sablotron, unixodbc, net-snmp, php, ...

[Frank Küster]

Anthony Towns  wrote:

> On Tue, Nov 01, 2005 at 12:41:09PM +0100, Henning Makholm wrote:
>> So, would anybody object if I set up a cronjob that emails the PTS
>> whenever a (source) package propagates to, or is removed from, testing?
>
> I won't so nobody'd object; but it's one of the things we agreed we
> wanted at the Vancouver meeting. I think there was going to be a
> -testing-changes list or something, perhaps? I forget exactly.

For sure I won't read a -testing-changes list, but still I am interested
in when one of *my* packages, or the ones I'm specifically interested
in, enter or leave testing.  So a mail to the PTS would be much better,
I think.

Regards, Frank
-- 
Frank Küster
Inst. f. Biochemie der Univ. Zürich
Debian Developer

Re: postinst scripts failing because a new conffile wasn't accepted: Is it a bug?

[Frank Küster]

Henning Makholm <[EMAIL PROTECTED]> wrote:

> In the long run, the user-friendly solution is probably to offer (via
> a debconf question that defaults to 'yes') to automatically rewrite
> the conffile to take the change into account. 

That can only be done if we change our policy with respect to maintainer
scripts changing of conffiles; and that I would not want unless
something like ucf does is integrated in dpkg.

Regards, Frank
-- 
Frank Küster
Inst. f. Biochemie der Univ. Zürich
Debian Developer

Bug#336852: ITP: libfacile-dev -- functional constraint library implemented in objective caml

[Steffen Joeris]

Package: wnpp
Severity: wishlist
Owner: Steffen Joeris <[EMAIL PROTECTED]>

I think the lib is needed by some kde applications.
The Kalzium developer told me that this lib is needed
during the build of Kalzium.


* Package name: libfacile-dev
  Version : 1.1
  Upstream Author : Copyright (C) 2001, CENA
* URL : http://www.recherche.enac.fr/opti/facile
* License : GNU Lesser General Public License
  Description : functional constraint library implemented in objective caml

 FaCiLe is a constraint programming library over integer finite domain
 written in Objective Caml. It offers all usual facilities to create
 and manipulate finite domain variables, arithmetic expressions and
 constraints (possibly non-linear), built-in global constraints and
 search goals. FaCiLe allows as well to build easily user-defined
 constraints and goals (including recursive ones), making pervasive use
 of OCaml higher-order functionals to provide a simple and flexible
 interface for the user. As FaCiLe is an OCaml library and not "yet
 another language", the user benefits from type inference and strong
 typing discipline, high level of abstraction, modules and objects
 system, as well as native code compilation efficiency, garbage
 collection and replay debugger, all features of OCaml (among many
 others) that allow to prototype and experiment quickly: modeling, data
 processing and interface are implemented with the same powerful and
 efficient language.
 .
 Web site: http://www.recherche.enac.fr/opti/facile


-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.12-1-686
Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1)


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Transition time: KDE, JACK, arts, sablotron, unixodbc, net-snmp, php, ...

[Henning Makholm]

Scripsit Henning Makholm <[EMAIL PROTECTED]>

> So, would anybody object if I set up a cronjob that emails the PTS
> whenever a (source) package propagates to, or is removed from, testing?

It turns out that PTS mail does not ordinary get sent to the
maintainer address, only to third-party subscribers. So I should
rephrase:

   Would anybody object if my cronjob emails the PTS *and* the
   maintainer address?

-- 
Henning Makholm  "The compile-time type checker for this
   language has proved to be a valuable filter which
  traps a significant proportion of programming errors."


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Transition time: KDE, JACK, arts, sablotron, unixodbc, net-snmp, php, ...

[Wouter Verhelst]

Op di, 01-11-2005 te 18:21 +0100, schreef Henning Makholm:
> Scripsit Henning Makholm <[EMAIL PROTECTED]>
> 
> > So, would anybody object if I set up a cronjob that emails the PTS
> > whenever a (source) package propagates to, or is removed from, testing?
> 
> It turns out that PTS mail does not ordinary get sent to the
> maintainer address, only to third-party subscribers. So I should
> rephrase:
> 
>Would anybody object if my cronjob emails the PTS *and* the
>maintainer address?

Why do it that way?

If you set up a cron job that only mails to the PTS (to a new keyword,
one that by default sends to the maintainer address), then maintainers
can disable those mails if they want to. I suggest to make this opt-out,
because those mails are about something which has a very real and direct
implication on the usefulness of your package to your users; but if
there's a lot of objection, surely you could make it opt-in and announce
it on -devel-announce?

-- 
The amount of time between slipping on the peel and landing on the
pavement is precisely one bananosecond


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: is the Debian mail server healthy?

[Nathanael Nerode]

Marc Haber wrote:

> On Sun, 30 Oct 2005 16:34:49 +0100, Stig Sandbeck Mathisen
> <[EMAIL PROTECTED]> wrote:
>>On Oct 30, 2005, at 10:52, Marc Haber wrote:
>>> I can confirm that master sits on some messages for days, such as this
>>> one, for example:
>>> |Received: from master.debian.org ([146.82.138.7])
>>> |by torres.zugschlus.de with esmtp (Exim 4.54)
>>> |id 1EVmC6-lm-8a
>>> |for [EMAIL PROTECTED]; Sat, 29 Oct 2005 10:36:07 +0200
>>> |Received: from qa by master.debian.org with local (Exim 3.35 1
>>> (Debian))
>>> |id 1EUOw2-0003y4-00; Tue, 25 Oct 2005 08:33:50 -0500
>>>
>>> So, there might be a problem, because these things happen quite
>>> regularly in the last few weeks.
>>
>>That does not mean that master has not tried to deliver it to you
>>during these days.
> 
> If it didn't try, it's broken. torres was available all the time and
> was actually receiving mail.

On a related note, the list archives are not working right.  Steve
Langasek's latest message to debian-devel-announce hasn't shown up
in the archives at all.  'serious' bug filed against listarchives, but maybe
someone reading this will know a faster way to check this out.

-- 
ksig --random|


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Sorting source packages to reduce build effort

[Nathanael Nerode]

Peter Samuelson wrote:

> 
>   [Daniel Ruoso]
>> > The question is: Is there a way (I mean, already implemented) to sort
>> > the packages putting the most used and less dependencies on the front
>> > and showing wich packages needs to be installed before the build can
>> > start?
> 
> [Goswin von Brederlow]
>> No. :(
> 
> Sounds like a job for tsort, with input from apt-rdepends -b or
> similar, driven by random scripting.

Tried to write such a thing, but apt-rdepends -b was segfaulting. 

-- 
ksig --random|


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Help: Bug#336469: pure-ftpd uninstallable : no pure-ftpd-common

[Nathanael Nerode]

Steve Langasek wrote:

> On Tue, Nov 01, 2005 at 09:27:06AM +0100, Henning Makholm wrote:
>> Scripsit Steve Langasek <[EMAIL PROTECTED]>
> 
>> > No, it's a bug in dpkg-dev, which should know how to set
>> > ${Source-Version} correctly for binNMUs.
I'm not clear which file actually puts this substitution in substvars; I
tried to track it down but couldn't find it.  Clearly whatever file does
that should provide two variables (Source-Version and Binary-Version are
indeed better names than I was thinking of).  If I found the file, I'd
write and submit a patch.

>> It can't really know, can it? If I have a control file with
> 
>>   Package: foo
>>   Architecture: any
> 
>>   Package: foo-data-extra
>>   Architecture: all
> 
>>   Package: foo-plugins
>>   Architecture: any
>>   Depends: foo (=${Source-Version}), foo-data-extra (=${Source-Version})
> 
>> then a binNMU ought to have foo-plugins depend on the binNMU'ed
>> version of foo, but on the common version of foo-data-extra.
>> If dpkg-gencontrol were to figure out that, it would need to parse a
>> lot of data that it currently doesn't. And even if it did it
>> correctly, the resulting behavior would be confusing.
> 
>> IMO it would be better to split ${Source-Version} into two substvars,
>> one of which includes binNMU suffixes and one of which doesn't.
> 
> Yes; sorry, I thought it was self-evident that Source-Version ought to
> refer to the *source* version, and that a new variable name is called for
> where the binary version is needed.

Right.  Hmm.

-- 
ksig --random|


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug#336698: dh_strip: debug data going to the wrong place

[Nathanael Nerode]

Steve Langasek wrote:

> Sorry, you're completely wrong.  The files installed in
> /usr/lib/debug/usr/lib are detached symbol files, that are loaded
> automatically by gdb -- *not* using LD_LIBRARY_PATH; and gdb looks for
> detached symbol files by prepending /usr/lib/debug to the full path of the
> original object file.  So there's no debhelper bug here.  If there are
> detached symbol files that aren't working, that bug must lie elsewhere.

Hmm.  Then what are those files in /usr/lib/debug
(not /usr/lib/debug/)?  I always thought those were the detached
symbol files, but I guess they must be something else -- what?

-- 
ksig --random|


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: ITP: pcmciautils -- PCMCIA userspace utilities (Linux 2.6.13+)

[Marc Haber]

On Sun, Jul 31, 2005 at 07:00:37PM +0200, Per Olofsson wrote:
> retitle 319583 ITP: pcmciautils -- PCMCIA userspace utilities (Linux 2.6.13+)
> thanks
> 
> I'm the maintainer of pcmcia-cs so I'm intending to package
> pcmciautils.

May I ask for the status of this ITP?

Greetings
Marc

-- 
-
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Mannheim, Germany  |  lose things."Winona Ryder | Fon: *49 621 72739834
Nordisch by Nature |  How to make an American Quilt | Fax: *49 621 72739835


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug#336698: dh_strip: debug data going to the wrong place

[Kurt Roeckx]

On Tue, Nov 01, 2005 at 02:12:04PM -0500, Nathanael Nerode wrote:
> Steve Langasek wrote:
> 
> > Sorry, you're completely wrong.  The files installed in
> > /usr/lib/debug/usr/lib are detached symbol files, that are loaded
> > automatically by gdb -- *not* using LD_LIBRARY_PATH; and gdb looks for
> > detached symbol files by prepending /usr/lib/debug to the full path of the
> > original object file.  So there's no debhelper bug here.  If there are
> > detached symbol files that aren't working, that bug must lie elsewhere.
> 
> Hmm.  Then what are those files in /usr/lib/debug
> (not /usr/lib/debug/)?  I always thought those were the detached
> symbol files, but I guess they must be something else -- what?

Those are real libraries that were not stripped, and those should
go away in favour of the detached version.


Kurt


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Help: Bug#336469: pure-ftpd uninstallable : no pure-ftpd-common

[Thomas Viehmann]

Nathanael Nerode wrote:
>>>Scripsit Steve Langasek <[EMAIL PROTECTED]>
No, it's a bug in dpkg-dev, which should know how to set
${Source-Version} correctly for binNMUs.

> I'm not clear which file actually puts this substitution in substvars; I
> tried to track it down but couldn't find it.  Clearly whatever file does
> that should provide two variables (Source-Version and Binary-Version are
> indeed better names than I was thinking of).  If I found the file, I'd
> write and submit a patch.
dpkg-dev: /usr/lib/dpkg/controllib.pl

Cheers

T.
-- 
Thomas Viehmann, http://thomas.viehmann.net/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Transition time: KDE, JACK, arts, sablotron, unixodbc, net-snmp, php, ...

[Nathanael Nerode]

Steve Langasek wrote:

> On Mon, Oct 31, 2005 at 02:54:49PM -0500, Nathanael Nerode wrote:
>> The enormous ABI transitions have been particularly hard, of course.  If
>> we can avoid ABI-breaking transitions in the future it would help.  :-)
> 
> Wholly unrealistic.  Libraries *do* undergo ABI changes; there are only a
> handful of library upstreams who know how to write a library interface
> that's proofed against future design decisions, and in most cases it's not
> worth the effort to try to write libs this way
Perhaps I didn't make myself clear.  I wasn't actually thinking of those,
since those can be handled quite nicely: if the library changes soname and
the symbols are versioned, both old and new versions can (and should)
coexist in separate packages and such transitions generally move pretty
smoothly (albeit slowly due to absent maintainers and lack of NMUs, which
is a different problem -- there simply should not have been that many
packages still depending on libpng10 when it was removed.)  

(At least for libraries with more than a few reverse depends; for those with
very few, they and their reverse depends can comfortably be pushed in
simultaneously if there's some maintainer coordination on lib transitions.)

> -- and it wouldn't save us 
> from C++ ABI changes anyway.
Now *that* was the sort of ABI change I was hoping we could avoid having
every release.  A major C ABI change would be even worse.

>> I think making a queue for transitions, so that they're basically one at
>> a time, would solve most remaining problems.
> 
> Doesn't work when lib maintainers don't coordinate.
Well, indeed, which was kind of, um, what I just said.  "Making a queue for
transitions" is a subset of "lib maintainers coordinating".

> A better option is to make britney more resilient in dealing with library
> transitions by keeping old binary packages around in testing instead of
> requiring them to be removed at the same time as the new version enters,
> which removes the need for all packages to be ready to enter testing at
> the
> same time.  This has been on the TODO list since it was discussed this
> past March in Vancouver, and is currently the top item on Anthony Towns'
> britney hacking list at .

The old source packages have to remain on the servers too in order to
satisfy license requirements; hope someone noticed that.

(Hmm, I wish there was a way there to pay him to change the priorities
-- what britney needs most is proper version tracking support for its RC bug
analysis, and I'd give some money for that; that's not listed in the notes
for 'next round of version tracking support' under debbugs either.)

Anyway, such a change won't do anything to help the people trying to install
'testing' 
* when the new library uses the same package name as the old, so users can't
install packages depending on the old and the new at the same time
(hence different package names)
* when it Conflicts: with the old, giving the same result (hence different
sonames; also different ports for different wire protocols, etc.)
* or when both can end up linked into the same binary with conflicting
symbols, causing crashes and misbehavior (hence versioned symbols)

If these issues aren't fixed, britney changes will just make 'testing' more
broken; imagine having two wire-incompatible binary packages of JACK,
trying to run on the same port, available in 'testing'.  In most cases,
fixes for all three of these problems, as noted, can be done right now,
without any britney support, by package maintainers, or at least by
upstream.  And if they are done, they remove much if not all of the
motivation for the britney changes.

So I guess I'm saying I'd rather concentrate on versioned symbols, proper
soname handling, and supporting coexisting old and new versions for heavily
used libraries; this will make more difference than any change in britney.

And when that doesn't suffice, library maintainers need to coordinate with
the release team.

-- 
ksig --random|


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Transition time: KDE, JACK, arts, sablotron, unixodbc, net-snmp, php, ...

[Nathanael Nerode]

Henning Makholm wrote:
> Well, the build-dependencies became fixed about 4 days ago (courtesy
> of a NMU by yours truly). Is 4 days enough to get something removed
> from testing?

Well, if you're curious, in this case autotrace had to be removed because
pstoedit had to be removed, and pstoedit had to be removed because
it had acquired a dependency on new gcc-4.0, and it seemed like a bad
idea to hold up the monster transition for new gcc-4.0 when new gcc-4.0
depends on new binutils and new glibc, both of which have multiple grave
bugs.

Automatic notice to the maintainers is a good idea, of course; didn't I hear
elsewhere on the thread that someone was implementing it?  :-)

-- 
ksig --random|


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: postinst scripts failing because a new conffile wasn't accepted: Is it a bug?

[Nathanael Nerode]

Petter Reinholdtsen wrote:

> My proposal to avoid such problem is to implement multilevel
> configuration, where the package default configuration and the local
> overrides are stored in separate files, making sure local
> configuration do not affect changes to the package default, and thus
> no question is asked during upgrade.
This is best design, certainly, but can be rather difficult to do if
upstream is not using a cooperative mechanism.  In contrast, if upstream
has DTRT, this should require no maintainer work.  Oh well.

-- 
ksig --random|


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Evolution Contacts

[Alejandro Bonilla]

hey,

Someone sent an email I dunno if here or in evolution-hackers ML but I also
lost  All my contacts after upgrading yesterday in Sid! ;0(

;-(

.Alejandro

--
Open WebMail Project (http://openwebmail.org)


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Best practices on system users and groups

[Javier Fernández-Sanguino Peña]

On Tue, Nov 01, 2005 at 11:14:59AM +0200, Lars Wirzenius wrote:
> Also, sticking all the tens of lines of boilerplate code into the
> postinst of every package that needs a system user is a good way to
> invite trouble. When the boilerplate has a bug (possibly because things
> change in the future), it will have to be fixed in dozes on of packages.
> It's oh so much more sensible to create a tool that postinsts can call:
> if boilerplate code is good enough, then it can easily be abstracted
> away.

I'm aware of that, but currently there's lot of packages that do it wrong in
any case, so having some boilerplate script they can be pointed to is
something good. Obviously, it would be best if this was provided as shell
functions that could be sourced by package's maintainer scripts. But that's
the second step, first lets document it properly, then implement it, and then
remove the code from the document and point to the implementation.

Regards

Javier


signature.asc
Description: Digital signature

Re: Best practices on system users and groups

[Javier Fernández-Sanguino Peña]

On Tue, Nov 01, 2005 at 11:14:59AM +0200, Lars Wirzenius wrote:
> ma, 2005-10-31 kello 22:03 +0100, Javier Fernández-Sanguino Peña
> kirjoitti:
> > After the feedback of the recent d-d thread, I've adapted the section I 
> > wrote
> > on the best practices related to system users and groups, it is currently
> > available at:
> > http://www.debian.org/doc/manuals/developers-reference/ch-best-pkging-practices.en.html#s-bpp-lower-privs
> > 
> > I would like developers to review and provide feedback for that section,
> > specially in form of patches. I'm considering doing a bug hunt for:
> 
> DON'T do this:
> 
>   addgroup --quiet --system $SERVER_GROUP 2>/dev/null ||true
> 
> When (not if!) addgroup fails, the poor system administrator gets no
> indication of it. This is a bug, and a pretty bad one. 

FWIW, that's partially based on what some package's postinst do (exim4-base, 
fetchmail,
ntp-simple, and proftp, for example). I've fixed the sample code to not 
redirect error messages (that probably should have been a '>/dev/null' and 
removed the '|| true' too.

> If adduser isn't quiet enough with --quiet, then fix that, don't hide
> real errors. Remove both the redirect and the "|| true".

Done in CVS.

Javier


signature.asc
Description: Digital signature

Re: Best practices on system users and groups

[Javier Fernández-Sanguino Peña]

On Tue, Nov 01, 2005 at 11:10:19AM +0100, Olaf van der Spek wrote:
> ma, 2005-10-31 kello 22:03 +0100, Javier Fernández-Sanguino Peña
> kirjoitti:
> > I would like developers to review and provide feedback for that section,
> > specially in form of patches. I'm considering doing a bug hunt for:
> 
> > Typically this means that the configuration files are owned by group, 
> > belong to the group of the system user and are mode 0640.
> 
> Owned by group? What group?

The system group. 

> > If the daemon logs to a directory under /var/log/ then *it* should be owned 
> > by the system user and rotated log files need not be changed ownership.
> 
> What does *it* mean? The directory or the log file?

The directory.

I've made some changes in CVS to clarify those.

Thanks

Javier


signature.asc
Description: Digital signature

Re: Best practices on system users and groups

[Javier Fernández-Sanguino Peña]

On Tue, Nov 01, 2005 at 04:53:33AM -0500, sean finney wrote:
> hi javier,
> 
> On Mon, Oct 31, 2005 at 10:03:01PM +0100, Javier Fernández-Sanguino Peña 
> wrote:
> > I would like developers to review and provide feedback for that section,
> 
> thanks for actually putting this into a document, however, i notice
> two problems:
> 
> - the addgroup/adduser functions mask the error status, yet do not
>   later check to see if the group was actually created.   this is doubly

Fixed in CVS.

>   the second thing i notice is that you arbitrarily modify the user in
>   question via usermod, which would override the local admin's changes.
>   i wonder whether it is even good to recommend this at all.

Usermod is only called if the user does not exist and the package creates
it. gdm, postgresql and logcheck already do this. In the example code,
if the system user exists, then usermod is not called, which is better than
what logcheck or postgresl currently do.

> i'd like to double-ack this remark.  even if the oft-mentioned "dh_user"
> were implemented, if there were a bug in this implementation, every
> affected package would have to be /rebuilt/ if the buggy code were
> actually in the postinsts.
> 
> if you're going to do this, it would be better to provide a program
> or a shell library that is sourced in the postinst, and then
> awrapper function which does all of this.  

Yes, that's what I'm currently more inclined at. I'm not certain which
package should provide this function but adduser seems like a valid candidate
for that.

Regards

Javier


signature.asc
Description: Digital signature

Re: Best practices on system users and groups

[Javier Fernández-Sanguino Peña]

On Tue, Nov 01, 2005 at 12:14:58PM +0100, Jonas Meurer wrote:
> On 31/10/2005 Javier Fernández-Sanguino Peña wrote:
> > After the feedback of the recent d-d thread, I've adapted the section I 
> > wrote
> > on the best practices related to system users and groups, it is currently
> > available at:
> > http://www.debian.org/doc/manuals/developers-reference/ch-best-pkging-practices.en.html#s-bpp-lower-privs
> 
> the group deletion has currently a problem. From 6.5.1.3 'Removing system
> users':

(...)

> 
> first, the 'if [ -n "$FIST_USER_GID" ] then' should better be
> 'if [ -n "$FIRST_USER_GID"]; then' (two small typos).

Fixed in CVS. Actually, the $FIST typo was in other places as well.

> second, and more important, the default GID for the group 'users' is 100
> for adduser, so the check above will always fail. system groups created
> via 'addgroup --system' have GIDs between 100 and 199.

Hmm.. You are right. That's not properly documented, I assumed USERS_GID was
not used for system users but it is.

> in my eyes it would be more sane to check for FIRST_SYSTEM_GID instead
> of USERS_GID.

There was no FIRST_SYSTEM_GID in my adduser.conf file (probably because of an
upgrade, when was this one introduced?), and it's not documented in the
manpage so I missed it.  of my adduser.conf file). I've changed the code
in CVS to use both FIRST_SYSTEM_GID and LAST_SYSTEM_GID (and to define them
if not present) and adjusted the delgroup code to make it similar to the
deluser code.

Thanks for the comments

Javier


signature.asc
Description: Digital signature

Re: Transition time: KDE, JACK, arts, sablotron, unixodbc, net-snmp, php, ...

[Andreas Barth]

* Anthony Towns (aj@azure.humbug.org.au) [051101 17:23]:
> On Tue, Nov 01, 2005 at 12:41:09PM +0100, Henning Makholm wrote:
> > So, would anybody object if I set up a cronjob that emails the PTS
> > whenever a (source) package propagates to, or is removed from, testing?
 
> I won't so nobody'd object; but it's one of the things we agreed we
> wanted at the Vancouver meeting. I think there was going to be a
> -testing-changes list or something, perhaps? I forget exactly.

We agreed to both maintainer mails (but PTS might be more appropriate
for that), and a summary to -testing-changes.

IOW, whoever shows code up for any of the tasks has some bonus points :)


Cheers,
Andi


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#336971: please order posts to a single bugreport by date/thread

[Stefano Zacchiroli]

Package: bugs.debian.org
Severity: minor

Today bugs.debian.org had some problem in receiving mails to [EMAIL PROTECTED]
timely. For example, in a discussion I started on #222138, mails reached
b.d.o in a non-causal order, making the bug report difficult to follow
on the web page.

Conversely, reading it downloading the mbox folder and using, for
example, mutt sorting the thread by date or thread is nice and easy to
follow.

I'm thus wondering: is it possible to sort the various "posts" to
[EMAIL PROTECTED] as seen on the web by date (or thread, or whatever) as many
MUA do? All the needed information seem to be already there.

Many thanks in advance,
Cheers.

-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.14-1-686
Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8)


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#336978: ITP: frown -- a parser generator for Haskell 98

[Arjan Oosting]

Package: wnpp
Severity: wishlist
Owner: Arjan Oosting <[EMAIL PROTECTED]>


* Package name: frown
  Version : 0.6
  Upstream Author : Ralf Hinze <[EMAIL PROTECTED]>
* URL : http://www.informatik.uni-bonn.de/~ralf/frown/index.html
* License : GPL version 2
  Description : parser generator for Haskell 98

 Frown is an LALR(k) parser generator for Haskell 98 written in
 Haskell 98. 
 .
 Its salient features are:
  - The generated parsers are time and space efficient. On the
downside, the parsers are quite large.
  - Frown generates four different types of parsers. As a common
characteristic, the parsers are genuinely functional 
(ie `table-free'); the states of the underlying LR automaton are
encoded as mutually recursive functions. Three output formats use
a typed stack representation, one format due to Ross Paterson
(code=stackless) works even without a stack.
  - Encoding states as functions means that each state can be treated
individually as opposed to a table driven-approach, which
necessitates a uniform treatment of states. For instance,
look-ahead is only used when necessary to resolve conflicts.
  - Frown comes with debugging and tracing facilities; the standard
output format due to Doaitse Swierstra (code=standard) may be
useful for teaching LR parsing.
  - Common grammatical patterns such as repetition of symbols can be
captured using rule schemata. There are several predefined rule
schemata.
  - Terminal symbols are arbitrary variable-free Haskell patterns or
guards. Both terminal and nonterminal symbols may have an
arbitrary number of synthesized attributes.
  - Frown comes with extensive documentation; several example grammars are 
included.
 .
 Furthermore, Frown supports the use of monadic lexers, monadic
 semantic actions, precedences and associativity, the generation of
 backtracking parsers, multiple start symbols, error reporting and a
 weak form of error correction.

A preliminary version of this package will soon be available on 
http://moonshine.dnsalias.org/debian/unstable

Greetings,

Arjan


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Debian based GNU/Solaris: pilot program

[Alex Ross]

Nexenta OS: Debian based GNU/Solaris
==

This is to announce Nexenta: the first-ever distribution that combines GNU and
OpenSolaris. As you might know, Sun Microsystems just opened Solaris kernel 
under
CDDL license, which allows one to build custom Operating Systems. Which we 
did...
created a new Debian based GNU/Solaris distribution with (the latest bits of)
Solaris kernel & core userland inside.

We'll open Nexenta web developer portal completely for the general public by
mid-November. Today we are launching a Pilot Program. Debian developers and the
entire Debian community - you are welcome to participate in the Pilot!

What is Nexenta OS today
=

Several things:

1) A working prototype that runs on our 32-bit laptops and AMD64 box; the
latter is used for development of the system itself, and it in turn runs our
entire development environment, and hosts the web portal (below).

2) 2,300 Debian packages available for immediate usage.

3) Developer's portal at http://www.gnusolaris.org - fully functional, with
downloads, APT repository, discussion forums, developer's "hack zone", bug
database, blogs, and numerous Solaris and free software related resources.

This will be 100% open and free-of-any-charge easy-to-install easy-to-use
distribution. Coming out soon!

The Future
===

We do hope that at some point, sooner rather than later, our changes (so far for
the most part just cleanups to build the DEBs in the new Solaris-like
environment) will be integrated with the upstream. At the end of the day - this
would be the right thing to do.

For Developers
==

There are probably very few projects that can come anywhere close to Nexenta OS,
in terms of the size, complexity and openness. The Nexenta project offers a rare
opportunity to take part in something as big as this mega-project at its early
stage - and make a meaningful contribution, ranging from selected improvements
and up to... well, the sky's the limit. One thing that makes it not only
challenging but also a rewarding experience is - the kernel. It's a true UNIX
(Solaris fully complies to The Open Group specifications). It's very stable,
extremely development-friendly, well  documented, cleanly architected, and well
written.

Contact
=

If interested, please send e-mail to , and tell us a few
words about yourself. We'll respond with a user/password.

Thanks!

Nexenta Team


www.gnusolaris.org




--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Debian based GNU/Solaris: pilot program

[Matthew Palmer]

On Tue, Nov 01, 2005 at 06:21:45PM -0800, Alex Ross wrote:
> 2) 2,300 Debian packages available for immediate usage.

[...]

> There are probably very few projects that can come anywhere close to 
> Nexenta OS,
> in terms of the size,

2300 << 15000, by my reckoning.

> and openness.

You keep using that word.  I do not think it means, what you think it means.

> If interested, please send e-mail to , and tell us 
> a few
> words about yourself. We'll respond with a user/password.

Not to poop on your parade, but please, next time you go to announce
something to a technical list like d-devel -- drop the marketing guff, just
stick to the useful info.

- Matt


signature.asc
Description: Digital signature

Re: Debian based GNU/Solaris: pilot program

[Alejandro Bonilla Beeche]

Matthew Palmer wrote:


On Tue, Nov 01, 2005 at 06:21:45PM -0800, Alex Ross wrote:
 


words about yourself. We'll respond with a user/password.
   



Not to poop on your parade, but please, next time you go to announce
something to a technical list like d-devel -- drop the marketing guff, just
stick to the useful info.
 

I found this email and comment rude. I can't get into my head that 
people from community and people moving and doing open source things can 
become or even give out this kind of rude comments.


I don't know if Alex works for Sun, but in anyway, he has the freedom 
and option to express himself as he wishes. Your comments, only bring FUD.


3x *shrug*

.Alejandro


- Matt
 




--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Debian based GNU/Solaris: pilot program

[Erast Benson]

On Wed, 2005-11-02 at 14:24 +1100, Matthew Palmer wrote:
> On Tue, Nov 01, 2005 at 06:21:45PM -0800, Alex Ross wrote:
> > 2) 2,300 Debian packages available for immediate usage.
> 
> [...]
> 
> > There are probably very few projects that can come anywhere close to 
> > Nexenta OS,
> > in terms of the size,
> 
> 2300 << 15000, by my reckoning.

very true. but Nexenta OS is not just number of packages. it also brings
something totally new and exciting to the Debian world.

...and number of packages growes as we speak. So, it is just a matter of
time.

Most hard and exciting part is to achive acceptable level of integration
between OpenSolaris Core and the rest of Debian world. Nobody did it
before. So, it is sort of not for newbies. :-)

Also this project requires *a lot of* hacking. To name a few, we are in
progress of integration Project Utopia(hal, dbus, pmount), gst, FUSE,
etc.

Erast


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Debian based GNU/Solaris: pilot program

[Matthew Palmer]

On Tue, Nov 01, 2005 at 09:07:08PM -0800, Erast Benson wrote:
> On Wed, 2005-11-02 at 14:24 +1100, Matthew Palmer wrote:
> > On Tue, Nov 01, 2005 at 06:21:45PM -0800, Alex Ross wrote:
> > > 2) 2,300 Debian packages available for immediate usage.
> > 
> > [...]
> > 
> > > There are probably very few projects that can come anywhere close to 
> > > Nexenta OS,
> > > in terms of the size,
> > 
> > 2300 << 15000, by my reckoning.
> 
> very true. but Nexenta OS is not just number of packages. it also brings
> something totally new and exciting to the Debian world.

I'm not discounting that it's new and exciting (I wouldn't say "totally",
but that's a matter of opinion), and I'm in fact quite interested in what
the technical benefits of running Debian on a Solaris kernel might be for my
needs.  However, Alex did specifically claim that Nexenta was of unmatched
size, and I was refuting that particular claim.

> ...and number of packages growes as we speak. So, it is just a matter of
> time.

I'm actually quite surprised that you've only been able to build 2300
packages out of Debian, but I presume there's significant hurdles which I'd
have trouble imagining standing in your way there.

> Most hard and exciting part is to achive acceptable level of integration
> between OpenSolaris Core and the rest of Debian world. Nobody did it
> before. So, it is sort of not for newbies. :-)

Right.  You want competent, clueful, technical people to work on the
project.  I suspect that these are the same people who are going to be
turned off (as I was) by unashamed marketing speak.  In fact, your message
has gotten me far more interested in Nexenta than the original did, as I can
see the sort of things that need to be done and might be interested in
working on some of those.

- Matt


signature.asc
Description: Digital signature

Re: Dummy packages and metapackages (call for consistency in the descriptions)

[Andreas Tille]

On Tue, 1 Nov 2005, Henrique de Moraes Holschuh wrote:


Well, I'd expect meta packages to have nothing on them


Why?  Was there any other definition than the link I posted that leads to
this assumption?

Kind regards

Andreas.

--
http://fam-tille.de


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Transition time: KDE, JACK, arts, sablotron, unixodbc, net-snmp, php, ...

[Steve Langasek]

On Tue, Nov 01, 2005 at 02:49:27PM -0500, Nathanael Nerode wrote:
> (Hmm, I wish there was a way there to pay him to change the priorities
> -- what britney needs most is proper version tracking support for its RC bug
> analysis, and I'd give some money for that; that's not listed in the notes
> for 'next round of version tracking support' under debbugs either.)

No; proper version tracking in britney is *much* less important than fixing
how we do library transitions.  We have other means of tracking RC bug
counts in testing and can easily override britney's concept of package
bugginess if necessary, but library transitions are a major, and currently
unavoidable, time sink for the release team.

> Anyway, such a change won't do anything to help the people trying to install
> 'testing' 
> * when the new library uses the same package name as the old, so users can't
> install packages depending on the old and the new at the same time
> (hence different package names)

which is rare; apt is the only package I know which does this for legitimate
reasons.

> * when it Conflicts: with the old, giving the same result (hence different
> sonames; also different ports for different wire protocols, etc.)

which is an issue for C++ ABI transitions, but the C++ ABI transition was
not the only reason for this transition to be so difficult -- the KDE change
wouldn't have been half as difficult if it had not been connected to a
number of other, unrelated soname changes.

> * or when both can end up linked into the same binary with conflicting
> symbols, causing crashes and misbehavior (hence versioned symbols)

which is a bug in those libraries that causes breakage on partial upgrades,
and we should fix this regardless of what happens to britney.

> If these issues aren't fixed, britney changes will just make 'testing' more
> broken; imagine having two wire-incompatible binary packages of JACK,
> trying to run on the same port, available in 'testing'.

No, this would not involve keeping multiple versions of the same binary
package in testing; there would be no way to install the older versions
anyway.  We're only talking about keeping old binary packages around which
are no longer available from the new source package, which is precisely the
case that is at issue with library transitions.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
[EMAIL PROTECTED]   http://www.debian.org/


signature.asc
Description: Digital signature

Re: Debian based GNU/Solaris: pilot program

[Matthew Palmer]

On Tue, Nov 01, 2005 at 09:32:49PM -0700, Alejandro Bonilla Beeche wrote:
> I don't know if Alex works for Sun, but in anyway, he has the freedom 
> and option to express himself as he wishes. Your comments, only bring FUD.

So I do *not* have the freedom and option to express myself as I wish?
Interesting.  However, you pass adverse comment on my adverse comment on
Alex's post, and that is (apparently) acceptable.

Well, I pass adverse comment on your adverse comment of my adverse comment,
and I look forward to your adverse comment on my adverse comment on your
adverse comment on my adverse comment about Alex's post.

BTW, FUD does actually have a distinct meaning, it's not some catchall for
"BadWords".

- Matt


signature.asc
Description: Digital signature

Re: Debian based GNU/Solaris: pilot program

[Erast Benson]

On Wed, 2005-11-02 at 17:16 +1100, Matthew Palmer wrote:
> On Tue, Nov 01, 2005 at 09:07:08PM -0800, Erast Benson wrote:
> > On Wed, 2005-11-02 at 14:24 +1100, Matthew Palmer wrote:
> > > On Tue, Nov 01, 2005 at 06:21:45PM -0800, Alex Ross wrote:
> > > > 2) 2,300 Debian packages available for immediate usage.
> > > 
> > > [...]
> > > 
> > > > There are probably very few projects that can come anywhere close to 
> > > > Nexenta OS,
> > > > in terms of the size,
> > > 
> > > 2300 << 15000, by my reckoning.
> > 
> > very true. but Nexenta OS is not just number of packages. it also brings
> > something totally new and exciting to the Debian world.
> 
> I'm not discounting that it's new and exciting (I wouldn't say "totally",
> but that's a matter of opinion), and I'm in fact quite interested in what
> the technical benefits of running Debian on a Solaris kernel might be for my
> needs.

This is an interesting question. You could find more answers by reading
materials at www.opensolaris.org.

One could benefit from the fact that OpenSolaris development is more
organized and centralized which leads to more tight control on its
interfaces. In short, OpenSolaris interfaces are stable. That brings
binary compatability across future OpenSolaris-based distros.

Another obvious benefit is that OpenSolaris licensed under open sourced
license which allowes to HW vendors to write their own drivers for all
that variety of existing specific hardware and yet not to open their IP.
But at the same time, this license(which is CDDL), 

Thecnical aspects benefits too. The kernel is *very* stable and highly
QA'd by Sun Microsystems. It brings bunch of advanced technologies and
complete(not just partial) implementations of many kernel interfaces.

>From user perspective, OpenSolaris core is well documented and
supported.

All that means: the end user of the system will not be forced to
re-compile drivers during installations, will not suffer from
half-implemented features, will not be forced to deal with source
packages and will benefit from both world - proprietery and open source.

Erast




-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Debian based GNU/Solaris: pilot program

[Alex Ross]

Matthew Palmer wrote:


I'm not discounting that it's new and exciting (I wouldn't say "totally", but
that's a matter of opinion), and I'm in fact quite interested in what the
technical benefits of running Debian on a Solaris kernel might be for my 
needs.  However, Alex did specifically claim that Nexenta was of unmatched 
size, and I was refuting that particular claim.


Hmm, did really I say unmatched?.. It's the size, *and* the early stage, *and*
the fact that it runs all our stuffs, *and* the kernel. It's a combination.


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Best practices on system users and groups

[Christian Perrier]

> Usermod is only called if the user does not exist and the package creates
> it. gdm, postgresql and logcheck already do this. In the example code,
> if the system user exists, then usermod is not called, which is better than
> what logcheck or postgresl currently do.


One very short notice for information: usermod recently got long
options added, similarly to useradd/userdel. This happened in passwd 4.0.13-4

(all utilities in passwd are slowly getting GNU-style long options added)

So, scripts calling it can use more readable options:

[EMAIL PROTECTED]:~/src/debian/dl10n> usermod -h
Usage: usermod [options] LOGIN

Options:
  -c, --comment COMMENT new value of the GECOS field
  -d, --home-dir HOME_DIR   new login directory for the new user account
-m, --move  Use -m option to move data to
the new directory
  -e, --expiredate EXPIRE_DATE  set account expiration date to EXPIRE_DATE
  -f, --inactive INACTIVE   set password inactive after expiration
to INACTIVE
  -g, --gid GROUP   force use GROUP as new initial login group
  -G, --groups GROUPS   list of supplementary groups
-a, --appendUse -a option to append the user
to the supplemental groups
  -h, --helpdisplay this help message and exit
  -l, --new-login LOGIN new value of the login name
  -L, --locklock the user account
  -o, --non-unique  allow using duplicate (non-unique) UID
  -p, --password PASSWORD   use encrypted password for the new password
  -s, --shell SHELL new login shell for the user account
  -u, --uid UID new UID for the user account
  -U, --unlock  unlock the user account


Of course, this is currently possible only in unstable



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]