dpkg semi-hijack - an announcement (also, triggers)

[Ian Jackson]

With this message I am unilaterally declaring myself a maintainer of
dpkg, and also declaring that Guillem is no longer a maintainer.

I have just made the hijack upload, dpkg 1.15.0, which contains
triggers support.  You can find the specification in doc/ in the
source, or in /usr/share/doc/dpkg-dev/triggers.text.gz.


It is with regret that I feel I have no option but to take this step.
The problem for me is Guillem, in his role as (what Raphael sees as)
current official authority for dpkg's C code.  Guillem:

  * Has been blocking the entry of triggers into lenny for 6 months
  * Has been blocking the entry of other bugfixes from me
(See full changelog entry below[3] for details)
  * Persists in making wholesale changes which he thinks are
stylistic improvements (including both actual code changes and
reformatting) but which are in some cases actually buggy,
despite me having explained the problems with them, and asked
him to stop [1][2]
  * Is blocking my consensual entry onto the team
  * Has not communicated at all adequately about these issues

I have spoken at length with Raphael on IRC.  We had a productive
conversation which convinced me that Raphael and I could have a
productive working relationship.  We were able to resolve our
difference over future workflow, at least setting aside the fate of
the triggers branch.

However Raphael made it clear to me that he was not willing for
triggers to be committed or uploaded until Guillem had reviewed and
merged it.  Not because Raphael had doubts about the code, but because
Guillem had said 6 months ago he wanted to review it and we should
give him "a few more days".

Today I have been merging triggers with current HEAD myself.  I have
had to revert wrong changes by Guillem and spend hours disentangling
conflicts caused by Guillem's formatting changes.  So Guillem's idea
of a merge will no doubt include reintroducing bugs and formatting
changes to meet Guillem's ideas of good style.

I conclude that Guillem must go.

Based on reviewing many of his commits, I think it will be a
manageable loss.  Guillem has made some useful commits but overall I
think the effect has been negative.  In the unlikely event that
Guillem is willing to work with me after this broadside, I would be
happy to review and consider his submissions.

Raphael and the other dpkg maintainers perhaps do not feel themselves
qualified to evaluate Guillem's technical skills versus my own.  In
any case in the absence of action from them I will not stand by.


To everyone else who has been on the dpkg team as an Uploader or
committer:

I am happy with the contributions you have been making.  I'd like to
invite you to continue to work as you have before.  I do not wish to
introduce any differences of status or process, and and do not wish to
put myself in charge over you.  I intend to work constructively with
you as an equal.

If you have any questions or doubts I'm going to make myself available
on #debian-dpkg on IRC.


Many people will think that I'm being arrogant and rude.  However, as
a good friend of mine once said, you can be rude or wrong, but not
both.  Guillem has been rude in that he has ignored my polite
representations and explanations, and he is also wrong.

Or to put it another way, I should be trusted more because:
 * Guillem has been making incorrect wholesale changes despite
   being told why not to do so
 * I have contributed important new features like Breaks
   and triggers, both of which are solid production quality
 * Guillem thinks that reformatting the code in free software is
   a good idea
 * I wrote the program in the first place

I have tried to resolve my problems by negotiation but this has
failed. [4]   Now comes the time for action.


Mechanics:

I have made an upload which merges the current git HEAD with triggers,
with a revised Uploaders field.

The new situation in alioth's main dpkg tree is:

   master-newThe new master tree, with triggers and everything
 Please commit here if you are not Guillem
 Commit only changes ready for immediate release

   iwj   My personal version of the master
 Do not commit here, but feel free to read

   master-oldThe old master tree from before this semi-hijack
 Do not use this tree, it is very stale
 Changes made based on this branch are difficult to merge

I have deleted the `master' branch ref for the moment to avoid anyone
being subjected to an unpleasant accident.  Around 48 hours from this
message I intend to rename `master-new' to `master' to confirm the
situation.

If you are a naive committer and don't care very much, you might want
to hold off until the dust has settled.

Aside from the above, please carry on with your the existing working
practices.

If you have a branch which has significant conflicts when you try to
pull, please just publish it somewhere and I will do the merge for you
to bring you

DD in Antarctic Continent?

[Hideki Yamane]

Hi list,

 Just a question.

 In Developer Locations page(*), it seems that Debian Developer is in 
 Antarctic Continent... awesome! Is it real??


 *) http://www.debian.org/devel/developers.loc

-- 
Regards,

 Hideki Yamane


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

Re: DD in Antarctic Continent?

[Clint Adams]

On Sun, Mar 09, 2008 at 10:14:14PM +0900, Hideki Yamane wrote:
> Hi list,
> 
>  Just a question.
> 
>  In Developer Locations page(*), it seems that Debian Developer is in 
>  Antarctic Continent... awesome! Is it real??

Not that one; someone made a sign error with his coordinates.


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

Re: dpkg semi-hijack - an announcement (also, triggers)

[Pierre Habouzit]

On dim, mar 09, 2008 at 11:28:13 +, Ian Jackson wrote:
> With this message I am unilaterally declaring myself a maintainer of
> dpkg, and also declaring that Guillem is no longer a maintainer.
> 
> I have just made the hijack upload, dpkg 1.15.0, which contains
> triggers support.  You can find the specification in doc/ in the
> source, or in /usr/share/doc/dpkg-dev/triggers.text.gz.

What a brilliant success for your new upload !

http://buildd.debian.org/~jeroen/status/package.php?p=dpkg

Congrats,
-- 
·O·  Pierre Habouzit
··O[EMAIL PROTECTED]
OOOhttp://www.madism.org


pgpFJl4xJAHc3.pgp
Description: PGP signature

Re: dpkg semi-hijack - an announcement (also, triggers)

[Daniel Jacobowitz]

On Sun, Mar 09, 2008 at 11:28:13AM +, Ian Jackson wrote:
> With this message I am unilaterally declaring myself a maintainer of
> dpkg, and also declaring that Guillem is no longer a maintainer.

How can you possibly consider this justified, without even passing
through the TC?  I find your decision to do this in appallingly bad
taste.  If I could produce a ten page essay on why I would be a
superior maintainer for one of your packages could I simply hijack it?

> [4] Why not ask the Technical Committee to rule ?
> 
> The TC has not shown great dynamism in recent months.  I have tried
> quite hard as a TC member to get various questions that were put to
> the TC decided, and the results have not been encouraging.
> 
> In any case, asking the TC about this at this stage would probably
> take at least a month or more.  This would make it that much harder
> for other packages' maintainers to make good use of triggers in lenny.
> It would also allow Guillem to continue making his undesirable
> wholesale edits in the meantime.
> 
> Finally, of course, I am on the Technical Committee.  For me to appeal
> this dispute to it in this way would seem too much like me using it as
> a personal bludgeon.

You want to talk about appearances.  It appears that you're acting as
inherently superior to another developer without involving the TC
because of the fact that you're already on it.

-- 
Daniel Jacobowitz
CodeSourcery


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

Please remove tkchooser

[Daniel van Eeden]

Dear QA,

Please remove the tkchooser package from Debian.

* First removal request in 2004:
http://lists.debian.org/debian-qa/2004/12/msg00018.html

* An important bug (#160136) is open for 5 years and 183 days.

* The Standards-Version is old (3.7.3 instead of 3.5.9.0)

* Upstream is abandoned (Last update 8 years ago):
http://www.thaumaturgy.net/~etgold/software/tkchooser2/

* The AppleTalk is not used a lot nowadays.

The QA page for tkchooser:
http://packages.qa.debian.org/t/tkchooser.html

Regards,

Daniel van Eeden


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

Re: DD in Antarctic Continent?

[Lionel Elie Mamane]

On Sun, Mar 09, 2008 at 10:05:34AM -0400, Clint Adams wrote:
> On Sun, Mar 09, 2008 at 10:14:14PM +0900, Hideki Yamane wrote:

>>  In Developer Locations page(*), it seems that Debian Developer is
>>  in Antarctic Continent... awesome! Is it real??

> Not that one; someone made a sign error with his coordinates.

So he's really in very-northern Finland/Sweden/Norway/Russia?

The other datapoint I'm questioning is:

 -51.12   -17.01

Google Maps doesn't report an island there...

-- 
Lionel


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

Re: dpkg semi-hijack - an announcement (also, triggers)

[Stefano Zacchiroli]

On Sun, Mar 09, 2008 at 11:28:13AM +, Ian Jackson wrote:
> With this message I am unilaterally declaring myself a maintainer of
> dpkg, and also declaring that Guillem is no longer a maintainer.

I find this unacceptable. This kind of situations are precisely those
in which people should resort to the Technical Committee.

Your main argument for not doing so is that it would take to long. This
is not a justification for bypassing TC and, de facto, declaring
yourself the "winner" of the dispute.

I do care about having triggers in Lenny, but you have no proof of
either of the following 2 facts:

1) the TC won't decide on time for Lenny

2) Guillem won't have time to review and integrate your changes on time
   for Lenny

No matter what, the default should be to *wait*, not to decide you are
on the right side and upload (with poor results apparently).

Your other argument for not resorting to the TC is that you are part of
it. I won't see a conflict of interest in you resorting the issue to the
TC at all. But of course I would expect from you that you won't take
part at all in the TC decision on the matter (no post to the bug log, no
private post, no vote).

Please resort to the TC and, in the meantime, revert your changes.

Cheers.

-- 
Stefano Zacchiroli -*- PhD in Computer Science ... now what?
[EMAIL PROTECTED],cs.unibo.it,debian.org}  -<%>-  http://upsilon.cc/zack/
(15:56:48)  Zack: e la demo dema ?/\All one has to do is hit the
(15:57:15)  Bac: no, la demo scema\/right keys at the right time


signature.asc
Description: Digital signature

Re: dpkg semi-hijack - an announcement (also, triggers)

[Pierre Habouzit]

On dim, mar 09, 2008 at 11:28:13 +, Ian Jackson wrote:
> REFERENCES, BACKGROUND and FURTHER DISCUSSION
> 
> 
> [1] Guillem persistently reintroducing errors, wholesale
> 
> Here is an example of a big code change made by Guillem:
>   
> http://git.debian.org/?p=dpkg/dpkg.git;a=commit;h=4e5846ccd3dcc33504aba8ef35a8962bccfd562e
> However this is wrong as I explained here:
>   http://lists.debian.org/debian-dpkg/2007/10/msg00200.html
> 
> I also emailed Guillem privately in August 2007 to ask that he stop
> this kind of thing.
> 
> Guillem has persisted with exactly the same mistake.  For example:
>   
> http://git.debian.org/?p=dpkg/dpkg.git;a=commit;h=02680ecbbbf6da2b023891a11b38ecce5346dbbd
> 
> It is one thing to make a coding mistake.  Everyone makes mistakes.
> It is quite another to make a widespread change, without discussion,
> and which is even if it is correct and worthwhile only at best
> stylistically helpful.  And then, after having been told that it was
> wrong, to continue requires a dogmatic belief in one's own
> correctness.

  AHAHAHAHAHA I totally missed that part in the first read. You're
totally on crack. Under C, NULL is defined as (void *)0
(and *NOT* (char *)0 that is TOTALLY wrong for obvious reasons), and
"someone" is not going to #define NULL  0.

  I fully support Guillem changes. C99 is almost 10 years old, we're
coding dpkg for Debian, in a sane C99/POSIX/X-OPEN/whatever environment.
Or are you also coding with 6-chars long variables names because
pre-ansi C didn't required compilers to remember more than 6 chars to
distinguish variable names ?


  If you're so afraid that one of the included headers defines NULL to
'0', then just assert (__builtin_types_compatible(NULL, void *))
somewhere and be done with it. But please, (char *)0 is not only wrong,
it's also tasteless and ugly to the eye.


> [2] Reformatting changes
> 
> Guillem has been engaging in a programme of reformatting and restyling
> of dpkg's code.
> 
> See for example #375711 where I submit a patch to correct what seemed
> to me obviously a tab/space conversion error, but which turned out to
> be deliberate.  (I first asked about this on debian-dpkg the 26th of
> June 2006 and there was no reply until over a month later on the 31st
> of May, so that I was already committed to my triggers code being
> based on the original, rather Guillem's, formatting.)  See also the
> examples above.
> 
> Everyone who works on free software knows that reformatting it is a
> no-no.  You work with the coding style that's already there.

  Oo I definitely don't live in the same world than yours.

-- 
·O·  Pierre Habouzit
··O[EMAIL PROTECTED]
OOOhttp://www.madism.org


pgpPopuljMASM.pgp
Description: PGP signature

Re: dpkg semi-hijack - an announcement (also, triggers)

[Kurt Roeckx]

On Sun, Mar 09, 2008 at 05:50:16PM +0100, Pierre Habouzit wrote:
> 
>   AHAHAHAHAHA I totally missed that part in the first read. You're
> totally on crack. Under C, NULL is defined as (void *)0
> (and *NOT* (char *)0 that is TOTALLY wrong for obvious reasons), and
> "someone" is not going to #define NULL  0.

It is defined like that on some OSs.  It's perfectly valid to do that.
In case of stdarg you need to cast NULL to a pointer.

> But please, (char *)0 is not only wrong,
> it's also tasteless and ugly to the eye.

I've suggested the use of (char *)NULL in the case that it's needed.


Kurt


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

Re: dpkg semi-hijack - an announcement (also, triggers)

[Raphael Hertzog]

On Sun, 09 Mar 2008, Ian Jackson wrote:
> With this message I am unilaterally declaring myself a maintainer of
> dpkg, and also declaring that Guillem is no longer a maintainer.

For the record, Ian has been removed from the "dpkg" group on Alioth and
we asked for an UNACCEPT of his upload, but I'm not sure it will be done
on time as none of the ftpmasters responded yet to my queries on IRC.

You can also read the log of #debian-dpkg since friday evening where I
spent two hours with him trying to find some compromise so that he can
contribute to dpkg. He just ignored everything we said and took this
ridiculous decision.
http://people.debian.org/~hertzog/debian-dpkg.log

Guillem has been working on the trigger integration this week and I told
so to Ian. But apparently he couldn't wait a few days more.

> I have spoken at length with Raphael on IRC.  We had a productive
> conversation which convinced me that Raphael and I could have a
> productive working relationship.  We were able to resolve our
> difference over future workflow, at least setting aside the fate of
> the triggers branch.

I don't know how you could ever expect me accepting your unilateral
removal of Guillem from the team.

> I have deleted the `master' branch ref for the moment to avoid anyone
> being subjected to an unpleasant accident.  Around 48 hours from this
> message I intend to rename `master-new' to `master' to confirm the
> situation.

Good choice, at least it's easy to clean up the mess now that you
can't commit any more.

> [1] Guillem persistently reintroducing errors, wholesale
> 
> Here is an example of a big code change made by Guillem:
>   
> http://git.debian.org/?p=dpkg/dpkg.git;a=commit;h=4e5846ccd3dcc33504aba8ef35a8962bccfd562e
> However this is wrong as I explained here:
>   http://lists.debian.org/debian-dpkg/2007/10/msg00200.html
> 
> I also emailed Guillem privately in August 2007 to ask that he stop
> this kind of thing.
> 
> Guillem has persisted with exactly the same mistake.  For example:
>   
> http://git.debian.org/?p=dpkg/dpkg.git;a=commit;h=02680ecbbbf6da2b023891a11b38ecce5346dbbd
> 
> It is one thing to make a coding mistake.  Everyone makes mistakes.
> It is quite another to make a widespread change, without discussion,
> and which is even if it is correct and worthwhile only at best
> stylistically helpful.  And then, after having been told that it was
> wrong, to continue requires a dogmatic belief in one's own
> correctness.

Can you tell us in which situations we have "#define NULL 0"
as opposed to "#define NULL (void*)0" ?

And why would the right fix be to revert all usage of NULL instead of,
say, add the proper define in a dpkg include file to override the bad
one that could come from... (I don't know see first question) ?

Don't you feel like that this argument is ridiculous to remove Guillem
from the team?

> [2] Reformatting changes
> 
> Guillem has been engaging in a programme of reformatting and restyling
> of dpkg's code.

I agree that it's necessarily a good idea to reformat the code but you
brought up the subject (in an unpleasant way, as usual) and as AFAIK he
didn't push more stylistic changes since then.

> [3] Changes that have been blocked by Guillem:
> 
> These are changes that I prepared or reviewed, and which have
> unaccountably not been included in mainline:

We still have about 60 patches in the BTS and only a tiny fraction comes
from you. If you could have been more pro-active, maybe more of your
patches would have been integrated but instead once the patch were ready
you disappeared and after X months you come back and complain
that we're blocking you.

And in fact, some of your changes have been merged already:
http://git.debian.org/?p=dpkg%2Fdpkg.git&a=search&h=master&st=author&s=Ian+Jackson

And more of your small changes would have been already integrated if you
didn't decide alone to make them depend on the prior integration of your
triggers branch (as you did for #432893).

Cheers,
-- 
Raphaël Hertzog

Le best-seller français mis à jour pour Debian Etch :
http://www.ouaza.com/livre/admin-debian/


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

Re: dpkg semi-hijack - an announcement (also, triggers)

[Pierre Habouzit]

On Sun, Mar 09, 2008 at 05:21:47PM +, Kurt Roeckx wrote:
> On Sun, Mar 09, 2008 at 05:50:16PM +0100, Pierre Habouzit wrote:
> > 
> >   AHAHAHAHAHA I totally missed that part in the first read. You're
> > totally on crack. Under C, NULL is defined as (void *)0
> > (and *NOT* (char *)0 that is TOTALLY wrong for obvious reasons), and
> > "someone" is not going to #define NULL  0.
> 
> It is defined like that on some OSs.

  Not in Debian, and dpkg is mostly a Debian tool, working on the glibc,
that defines NULL the proper way.

>  It's perfectly valid to do that.

  No it's not, and OSes that do, are not C99 compliant (and not even C89 IIRC,
but I've no C89 spec at hand to check).

> In case of stdarg you need to cast NULL to a pointer.

That's the very reason why NULL shall be a pointer.

Here is the relevant C99 quote:


§ 7.17 Common definitions 
[...]
3 The macros are
  NULL
  which expands to an implementation-defined null pointer constant; and


0 is not a pointer, hence disqualifies.

Cheers,
-- 
·O·  Pierre Habouzit
··O[EMAIL PROTECTED]
OOOhttp://www.madism.org


pgpSZTl8htzfa.pgp
Description: PGP signature

Re: Please remove tkchooser

[Jonny Lamb]

On Sun, Mar 09, 2008 at 04:30:01PM +0100, Daniel van Eeden wrote:
> Dear QA,
> 
> Please remove the tkchooser package from Debian.

The following page contains information on requesting a package removal:

http://wiki.debian.org/ftpmaster_Removals

Regards,

-- 
Jonny Lamb, UK   [EMAIL PROTECTED]
http://jonnylamb.com GPG: 0x2E039402


signature.asc
Description: Digital signature

Re: dpkg semi-hijack - an announcement (also, triggers)

[Raphael Hertzog]

On Sun, 09 Mar 2008, Raphael Hertzog wrote:
> > [2] Reformatting changes
> > 
> > Guillem has been engaging in a programme of reformatting and restyling
> > of dpkg's code.
> 
> I agree that it's necessarily a good idea to reformat the code but you
   ^
   not
> brought up the subject (in an unpleasant way, as usual) and as AFAIK he
> didn't push more stylistic changes since then.

Cheers,
-- 
Raphaël Hertzog

Le best-seller français mis à jour pour Debian Etch :
http://www.ouaza.com/livre/admin-debian/


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

Re: dpkg semi-hijack - an announcement (also, triggers)

[Kurt Roeckx]

On Sun, Mar 09, 2008 at 06:34:48PM +0100, Pierre Habouzit wrote:
> On Sun, Mar 09, 2008 at 05:21:47PM +, Kurt Roeckx wrote:
> > On Sun, Mar 09, 2008 at 05:50:16PM +0100, Pierre Habouzit wrote:
> > > 
> > >   AHAHAHAHAHA I totally missed that part in the first read. You're
> > > totally on crack. Under C, NULL is defined as (void *)0
> > > (and *NOT* (char *)0 that is TOTALLY wrong for obvious reasons), and
> > > "someone" is not going to #define NULL  0.
> > 
> > It is defined like that on some OSs.
> 
>   Not in Debian, and dpkg is mostly a Debian tool, working on the glibc,
> that defines NULL the proper way.
> 
> >  It's perfectly valid to do that.
> 
>   No it's not, and OSes that do, are not C99 compliant (and not even C89 IIRC,
> but I've no C89 spec at hand to check).
> 
> > In case of stdarg you need to cast NULL to a pointer.
> 
> That's the very reason why NULL shall be a pointer.
> 
> Here is the relevant C99 quote:
> 
> 
> § 7.17 Common definitions 
> [...]
> 3 The macros are
> NULL
>   which expands to an implementation-defined null pointer constant; and

6.3.2.3 Pointers
[...]
3  An integer constant expression with the value 0, or
   such an expression cast to type void *, is called a null
   pointer constant.55) If a null pointer constant is assigned
   to or compared for equality to a pointer, the constant is
   converted to a pointer of that type.  Such a pointer, called
   a null pointer, is guaranteed to compare unequal to a
   pointer to any object or function.
[...]
55) The macro NULL is defined in  as a null pointer
constant; see 7.17.


Kurt


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

Re: dpkg semi-hijack - an announcement (also, triggers)

[Faidon Liambotis]

Ian Jackson wrote:

[4] Why not ask the Technical Committee to rule ?

The TC has not shown great dynamism in recent months.  I have tried
quite hard as a TC member to get various questions that were put to
the TC decided, and the results have not been encouraging.

In any case, asking the TC about this at this stage would probably
take at least a month or more.  This would make it that much harder
for other packages' maintainers to make good use of triggers in lenny.
It would also allow Guillem to continue making his undesirable
wholesale edits in the meantime.

Finally, of course, I am on the Technical Committee.  For me to appeal
this dispute to it in this way would seem too much like me using it as
a personal bludgeon.
If you don't recognize the authority or the necessity of the Technical 
Committee on such matters but instead decide take matters into your own 
hands, I'd expect from you to resign from the comittee.


I can't understand how a Debian Developer, let alone a Technical 
Comittee member, can find it acceptable to hijack a package actively 
maintained because of technical disagreements with its maintainer.

Especially if that package is a core package such as dpkg.

You're hurting the credibility of the comittee and of the whole project.
That's much more important than a disagreement on a technical matter.

Regards,
Faidon


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

Re: dpkg semi-hijack - an announcement (also, triggers)

[Kurt Roeckx]

On Sun, Mar 09, 2008 at 06:48:41PM +0100, Kurt Roeckx wrote:
> 6.3.2.3 Pointers
> [...]
> 3  An integer constant expression with the value 0, or
>such an expression cast to type void *, is called a null
>pointer constant.55) If a null pointer constant is assigned
>to or compared for equality to a pointer, the constant is
>converted to a pointer of that type.  Such a pointer, called
>a null pointer, is guaranteed to compare unequal to a
>pointer to any object or function.

That's not really want the C99 version said.  It says:
  3  An integer constant expression with the value 0, or
 such an expression cast to type void *, is called a null
 pointer constant.55) If a null pointer constant is converted
 to a pointer type, the resulting pointer, called
 a null pointer, is guaranteed to compare unequal to a
 pointer to any object or function.


Kurt


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

Re: dpkg semi-hijack - an announcement (also, triggers)

[Pierre Habouzit]

On Sun, Mar 09, 2008 at 06:00:31PM +, Kurt Roeckx wrote:
> On Sun, Mar 09, 2008 at 06:48:41PM +0100, Kurt Roeckx wrote:
> > 6.3.2.3 Pointers
> > [...]
> > 3  An integer constant expression with the value 0, or
> >such an expression cast to type void *, is called a null
> >pointer constant.55) If a null pointer constant is assigned
> >to or compared for equality to a pointer, the constant is
> >converted to a pointer of that type.  Such a pointer, called
> >a null pointer, is guaranteed to compare unequal to a
> >pointer to any object or function.
> 
> That's not really want the C99 version said.  It says:
>   3  An integer constant expression with the value 0, or
>  such an expression cast to type void *, is called a null
>  pointer constant.55)

Well, I read it that way:

  An integer constant expression with the value 0 (or such an
  expression) cast to type void *, is called a null pointer constant.55)

IOW, a null pointer constant is similar to (void *)0.

-- 
·O·  Pierre Habouzit
··O[EMAIL PROTECTED]
OOOhttp://www.madism.org


pgpWPAsJS0OE8.pgp
Description: PGP signature

Re: dpkg semi-hijack - an announcement (also, triggers)

[Mohammed Adnène Trojette]

On Sun, Mar 09, 2008, Ian Jackson wrote:
> Finally, of course, I am on the Technical Committee.  For me to appeal
> this dispute to it in this way would seem too much like me using it as
> a personal bludgeon.

You could also appeal this dispute to it and not take part in the vote,
so that the TC's decision is not tainted with your personal opinion.

-- 
Mohammed Adnène Trojette


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

Re: dpkg semi-hijack - an announcement (also, triggers)

[Daniel Jacobowitz]

On Sun, Mar 09, 2008 at 06:34:48PM +0100, Pierre Habouzit wrote:
> Here is the relevant C99 quote:
> 
> 
> § 7.17 Common definitions 
> [...]
> 3 The macros are
> NULL
>   which expands to an implementation-defined null pointer constant; and
> 
> 
> 0 is not a pointer, hence disqualifies.

Just to confirm Kurt's point, 0 is a "null pointer constant" in C.
But it is not necessarily a pointer.  You can't terminate a varargs
list of pointers (e.g. execl) with NULL unless you cast it.

-- 
Daniel Jacobowitz
CodeSourcery


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

Re: dpkg semi-hijack - an announcement (also, triggers)

[Lionel Elie Mamane]

On Sun, Mar 09, 2008 at 05:50:16PM +0100, Pierre Habouzit wrote:

>   I fully support Guillem changes. C99 is almost 10 years old, we're
> coding dpkg for Debian, in a sane C99/POSIX/X-OPEN/whatever
> environment.

Hmm... Not really. GCC's default mode is still C89+GNU extensions. It
is true that the GNU extensions overlap C99 somewhat. But this does
not destroy the validity of your claim (that dpkg is coded for a
relatively decently modern compiler).

-- 
Lionel


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

Re: dpkg semi-hijack - an announcement (also, triggers)

[Daniel Jacobowitz]

On Sun, Mar 09, 2008 at 07:09:39PM +0100, Pierre Habouzit wrote:
> Well, I read it that way:
> 
>   An integer constant expression with the value 0 (or such an
>   expression) cast to type void *, is called a null pointer constant.55)

Well, don't read it that way - the commas in the original version are
correct and intentional :-)

-- 
Daniel Jacobowitz
CodeSourcery


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

Re: DD in Antarctic Continent?

[Clint Adams]

On Sun, Mar 09, 2008 at 05:13:14PM +0100, Lionel Elie Mamane wrote:
> So he's really in very-northern Finland/Sweden/Norway/Russia?

If I recall correctly, he was somewhere in or around Michigan.


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

Re: dpkg semi-hijack - an announcement (also, triggers)

[Pierre Habouzit]

On Sun, Mar 09, 2008 at 06:16:03PM +, Lionel Elie Mamane wrote:
> On Sun, Mar 09, 2008 at 05:50:16PM +0100, Pierre Habouzit wrote:
> 
> >   I fully support Guillem changes. C99 is almost 10 years old, we're
> > coding dpkg for Debian, in a sane C99/POSIX/X-OPEN/whatever
> > environment.
> 
> Hmm... Not really. GCC's default mode is still C89+GNU extensions. It
> is true that the GNU extensions overlap C99 somewhat. But this does
> not destroy the validity of your claim (that dpkg is coded for a
> relatively decently modern compiler).

  dpkg is built using gcc --std=gnu99.

-- 
·O·  Pierre Habouzit
··O[EMAIL PROTECTED]
OOOhttp://www.madism.org


pgpzQc0plyevs.pgp
Description: PGP signature

Re: dpkg semi-hijack - an announcement (also, triggers)

[Lionel Elie Mamane]

On Sun, Mar 09, 2008 at 07:17:44PM +0100, Pierre Habouzit wrote:
> On Sun, Mar 09, 2008 at 06:16:03PM +, Lionel Elie Mamane wrote:
>> On Sun, Mar 09, 2008 at 05:50:16PM +0100, Pierre Habouzit wrote:

>>>   I fully support Guillem changes. C99 is almost 10 years old, we're
>>> coding dpkg for Debian, in a sane C99/POSIX/X-OPEN/whatever
>>> environment.

>> Hmm... Not really. GCC's default mode is still C89+GNU extensions. It
>> is true that the GNU extensions overlap C99 somewhat. But this does
>> not destroy the validity of your claim (that dpkg is coded for a
>> relatively decently modern compiler).

>   dpkg is built using gcc --std=gnu99.

Ah, then, yes.

-- 
Lionel


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

Re: DD in Antarctic Continent?

[Henrique de Moraes Holschuh]

On Sun, 09 Mar 2008, Clint Adams wrote:
> On Sun, Mar 09, 2008 at 10:14:14PM +0900, Hideki Yamane wrote:
> >  In Developer Locations page(*), it seems that Debian Developer is in 
> >  Antarctic Continent... awesome! Is it real??
> 
> Not that one; someone made a sign error with his coordinates.

Can we file a bug and get it fixed, by NMLU (non-maintainer LDAP update ;-)
) if necessary?

-- 
  "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: dpkg semi-hijack - an announcement (also, triggers)

[Ian Jackson]

Pierre Habouzit writes ("Re: dpkg semi-hijack - an announcement (also, 
triggers)"):
> What a brilliant success for your new upload !
> http://buildd.debian.org/~jeroen/status/package.php?p=dpkg

This was due to a buggy translation update (predating my efforts, but
not yet uploaded by anyone).  It seems that I used a lenny chroot
instead of a sid one, and you get the FTBFS on sid only.

This will be fixed shortly.

Ian.


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

Re: DD in Antarctic Continent?

[Roberto C . Sánchez]

On Sun, Mar 09, 2008 at 02:17:04PM -0400, Clint Adams wrote:
> On Sun, Mar 09, 2008 at 05:13:14PM +0100, Lionel Elie Mamane wrote:
> > So he's really in very-northern Finland/Sweden/Norway/Russia?
> 
> If I recall correctly, he was somewhere in or around Michigan.
> 
Which really is not all that different from very-northern
Finland/Sweden/Norway/Russia :-)

Regards,

-Roberto

-- 
Roberto C. Sánchez
http://people.connexer.com/~roberto
http://www.connexer.com


signature.asc
Description: Digital signature

Re: dpkg semi-hijack - an announcement (also, triggers)

[Ian Jackson]

Pierre Habouzit writes ("Re: dpkg semi-hijack - an announcement (also, 
triggers)"):
>   AHAHAHAHAHA I totally missed that part in the first read. You're
> totally on crack. Under C, NULL is defined as (void *)0
> (and *NOT* (char *)0 that is TOTALLY wrong for obvious reasons), and
> "someone" is not going to #define NULL  0.

ISO/IEC 9899:1999 (E) aka C99:

Section 6.3.2.3:

  An integer constant expression with the value 0, or such an
  expression cast to type void*, is called a _null pointer
  constant_. [*]  If a null pointer constant is converted to a pointer
  type, the resulting pointer, called a null pointer, is guaranteed to
  compare unequal to a pointer to any object or function.

  [*] The macro NULL is defined in  (and other headers) as a
  null pointer constant; see 7.17.

Section 7.17:

  The macros are
   NULL
  which expands to an implementation-defined null pointer constant; ...

Note that a `null pointer constant' is only a pointer if it is
converted to a pointer type.  Just `0' is an `integer constant
expression with the value 0', and is therefore a `null pointer
constant' which is therefore permitted as a definition for NULL.
So C99 permits an implementation (that is, permits stddef.h) to
  #define NULL 0

>   If you're so afraid that one of the included headers defines NULL to
> '0', then just assert (__builtin_types_compatible(NULL, void *))
> somewhere and be done with it. But please, (char *)0 is not only wrong,
> it's also tasteless and ugly to the eye.

In what way is (char*)0 wrong in these contexts ?

Ian.


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

Re: dpkg semi-hijack - an announcement (also, triggers)

[Raphael Hertzog]

On Sun, 09 Mar 2008, Raphael Hertzog wrote:
> On Sun, 09 Mar 2008, Ian Jackson wrote:
> > With this message I am unilaterally declaring myself a maintainer of
> > dpkg, and also declaring that Guillem is no longer a maintainer.
> 
> For the record, Ian has been removed from the "dpkg" group on Alioth and
> we asked for an UNACCEPT of his upload, but I'm not sure it will be done
> on time as none of the ftpmasters responded yet to my queries on IRC.

The package got unaccepted by Anthony Towns.

Cheers,
-- 
Raphaël Hertzog

Le best-seller français mis à jour pour Debian Etch :
http://www.ouaza.com/livre/admin-debian/


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

Re: dpkg semi-hijack - an announcement (also, triggers)

[Mike Bird]

On Sun March 9 2008 12:27:59 Faidon Liambotis wrote:
> I can't understand how a Debian Developer, let alone a Technical
> Comittee member, can find it acceptable to hijack a package actively
> maintained because of technical disagreements with its maintainer.
> Especially if that package is a core package such as dpkg.

How would you feel if a bunch of less-than-stellar programmers took over
one of your programs (Ian wrote dpkg) and blocked your changes for six
months while they reformatted the white space and tried to learn basic
C programming?

The old dpkg team has not so much been actively maintaining dpkg as
actively blocking maintenance of dpkg.  They've been fumbling around
for six months, messing with white space and making minor changes,
while blocking Ian's enhancements.  Every indication is that the old
dpkg team is way out of its depth and should work their way up through
simpler programming tasks before taking on something as crucial as dpkg.

On the other hand, fer crissake Ian stop using 0 for NULL!  You can use
(char*)NULL if it helps.

--Mike Bird


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

Re: dpkg semi-hijack - an announcement (also, triggers)

[Ian Jackson]

Raphael Hertzog writes ("Re: dpkg semi-hijack - an announcement (also, 
triggers)"):
> You can also read the log of #debian-dpkg since friday evening where I
> spent two hours with him trying to find some compromise so that he can
> contribute to dpkg. He just ignored everything we said and took this
> ridiculous decision.
> http://people.debian.org/~hertzog/debian-dpkg.log

Please do go and read it.  Here is the part right at the end, just
where it's all going wrong:

 22:16  Perhaps I'm misunderstanding.  Just so that we're completely 
clear:  Your view is that you are not willing to agree the 
commit-to-trunk, or upload, of triggers, without Guillem's 
blessing ?
 22:17  (at this point), I believe?
 22:17  yes (at least for a few days more until we really have no other 
  choices)

I got fed up of waiting.  I asked in August.  I asked again in October
and November.  I asked again two weeks ago.  And now I'm told `few
more days'.

Guillem said nothing to me personally.  Nothing!  All I have is an
idea from you that it will be a `few more days'.

> > I have deleted the `master' branch ref for the moment to avoid anyone
> > being subjected to an unpleasant accident.  Around 48 hours from this
> > message I intend to rename `master-new' to `master' to confirm the
> > situation.
> 
> Good choice, at least it's easy to clean up the mess now that you
> can't commit any more.

Well, making a mess in a revision control system is never a good idea.

> Can you tell us in which situations we have "#define NULL 0"
> as opposed to "#define NULL (void*)0" ?

Some C libraries do this for the benefit of broken old programs which
use NULL when they mean an integer or character0.  C99 says it's legal
for NULL to be 0.

> And why would the right fix be to revert all usage of NULL instead of,
> say, add the proper define in a dpkg include file to override the bad
> one that could come from... (I don't know see first question) ?

Err, redefining NULL in dpkg ?

> Don't you feel like that this argument is ridiculous to remove Guillem
> from the team?

This and the other things I've complained of.  He won't discuss these
matters with me.

> > [2] Reformatting changes
> > 
> > Guillem has been engaging in a programme of reformatting and restyling
> > of dpkg's code.
> 
> I agree that it's necessarily a good idea to reformat the code but you
> brought up the subject (in an unpleasant way, as usual) and as AFAIK he
> didn't push more stylistic changes since then.

Some commits:
  d9091a81b6dc449038821451696577ebbd270715  21 Jan   Refactor max open...
  02680ecbbbf6da2b023891a11b38ecce5346dbbd   9 Jan   Use NULL instead of 0

> We still have about 60 patches in the BTS and only a tiny fraction comes
> from you. If you could have been more pro-active, maybe more of your
> patches would have been integrated but instead once the patch were ready
> you disappeared and after X months you come back and complain
> that we're blocking you.

We had this discussion on IRC.  No-one told me that after triaging a
bug to make a patch I should ping it every few weeks to chase it into
the tree.  Indeed that's a terrible way of working.  Am I supposed to
keep myself a list of all of my lost work ?

> And more of your small changes would have been already integrated if you
> didn't decide alone to make them depend on the prior integration of your
> triggers branch (as you did for #432893).

There was an merge conflict with my triggers branch.  It was make the
fix depend on the triggers branch or do it twice.  Since the triggers
branch ought to have been committed long ago I don't see the problem.

Ian.


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

Re: dpkg semi-hijack - an announcement (also, triggers)

[William Pitcock]

Hi,

On Sun, 2008-03-09 at 19:27 +, Faidon Liambotis wrote:
> You're hurting the credibility of the comittee and of the whole
> project.
> That's much more important than a disagreement on a technical matter.

On the other hand allowing dpkg to be maintained in the way that it
presently is, is also hurting the credibility of the whole project.

NOT THAT I AGREE WITH THE HIJACKING. That too, is not the proper
solution to this.

William


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

Re: dpkg semi-hijack - an announcement (also, triggers)

[Riku Voipio]

On Sun, Mar 09, 2008 at 06:34:36PM +, Ian Jackson wrote:
> Pierre Habouzit writes ("Re: dpkg semi-hijack - an announcement (also, 
> triggers)"):
> >   If you're so afraid that one of the included headers defines NULL to
> > '0', then just assert (__builtin_types_compatible(NULL, void *))
> > somewhere and be done with it. But please, (char *)0 is not only wrong,
> > it's also tasteless and ugly to the eye.

> In what way is (char*)0 wrong in these contexts ?

According to execlp manpage:

The list of arguments must be terminated by a NULL pointer,
and, since these are vari‐adic functions, this pointer _must_
be cast (char *) NULL.




-- 
"rm -rf" only sounds scary if you don't have backups


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

Re: dpkg semi-hijack - an announcement (also, triggers)

[Pierre Habouzit]

On Sun, Mar 09, 2008 at 06:53:23PM +, Mike Bird wrote:
> On Sun March 9 2008 12:27:59 Faidon Liambotis wrote:
> > I can't understand how a Debian Developer, let alone a Technical
> > Comittee member, can find it acceptable to hijack a package actively
> > maintained because of technical disagreements with its maintainer.
> > Especially if that package is a core package such as dpkg.
> 
> How would you feel if a bunch of less-than-stellar programmers took over
> one of your programs (Ian wrote dpkg) and blocked your changes for six
> months while they reformatted the white space and tried to learn basic
> C programming?

  /usr/share/doc/dpkg/changelog.Debian.gz shows that the dpkg team
closed 148 bugs in the last 6 months. How many did you closed in the
same period ?
-- 
·O·  Pierre Habouzit
··O[EMAIL PROTECTED]
OOOhttp://www.madism.org


pgpLGDqeWLoFj.pgp
Description: PGP signature

Re: dpkg semi-hijack - an announcement (also, triggers)

[Raphael Hertzog]

On Sun, 09 Mar 2008, Ian Jackson wrote:
> > Can you tell us in which situations we have "#define NULL 0"
> > as opposed to "#define NULL (void*)0" ?
> 
> Some C libraries do this for the benefit of broken old programs which
> use NULL when they mean an integer or character0.  C99 says it's legal
> for NULL to be 0.

Fortunately Debian is concerned with the glibc only. And from what I can
read (by others in this thread), using NULL instead of (char*)0 is always
ok except when used to finish a vararg where (char*)NULL would be a simple
compromise between readability and correctness.

> > Don't you feel like that this argument is ridiculous to remove Guillem
> > from the team?
> 
> This and the other things I've complained of.  He won't discuss these
> matters with me.

And I can understand him, you have never shown any willingness to discuss
calmly and to make compromise.

(And your coding style preference sucks and you cry when it evolves in
dpkg because others dare touch your original code)

> > I agree that it's necessarily a good idea to reformat the code but you
> > brought up the subject (in an unpleasant way, as usual) and as AFAIK he
> > didn't push more stylistic changes since then.
> 
> Some commits:
>   d9091a81b6dc449038821451696577ebbd270715  21 Jan   Refactor max open...
>   02680ecbbbf6da2b023891a11b38ecce5346dbbd   9 Jan   Use NULL instead of 0

When you complained, it was about indenting and spaces. Here I see
improvements in readability of the program and a nicer check to decide
between two ways to close all the open file descriptors (without
hardcoding a specific OS in #ifdef).

Cheers,
-- 
Raphaël Hertzog

Le best-seller français mis à jour pour Debian Etch :
http://www.ouaza.com/livre/admin-debian/


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

Re: dpkg semi-hijack - an announcement (also, triggers)

[Ian Jackson]

Raphael Hertzog writes ("Re: dpkg semi-hijack - an announcement (also, 
triggers)"):
> The package got unaccepted by Anthony Towns.

OH FOR FUCK'S SAKE WHAT DOES IT TAKE TO GET SOMETHING DONE AROUND HERE?

SIX MONTHS THIS IMPORTANT CODE HAS JUST BEEN SITTING THERE


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

Re: dpkg semi-hijack - an announcement (also, triggers)

[Ian Jackson]

Ian Jackson writes ("Re: dpkg semi-hijack - an announcement (also, triggers)"):
> Raphael Hertzog writes ("Re: dpkg semi-hijack - an announcement (also, 
> triggers)"):
> OH FOR FUCK'S SAKE WHAT DOES IT TAKE TO GET SOMETHING DONE AROUND HERE?
> SIX MONTHS THIS IMPORTANT CODE HAS JUST BEEN SITTING THERE

My tree is here:
 http://git.debian.org/?p=users/iwj/dpkg.git;a=summary

This has 1.15.1 which should fix the broken German translation which
causes the FTBFS.  I'm going to go away and calm down and/or find
something to hit.

Ian.


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

Bug#470185: RFH: jove -- Jonathan's Own Version of Emacs - a compact, powerful editor

[Cord Beermann]

Package: wnpp
Severity: normal

I request assistance with maintaining the jove package.

The package description is:
 Jove is a compact, powerful Emacs-style text-editor. It provides the common
 emacs keyboard bindings, together with a reasonable assortment of the most
 popular advanced features (e.g. interactive shell windows, compile-it,
 language specific modes) while weighing in with CPU, memory, and disk
 requirements comparable to vi(1).



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

Bug#470187: RFH: nn -- Heavy-duty USENET news reader (curses-based client)

[Cord Beermann]

Package: wnpp
Severity: normal

I request assistance with maintaining the nn package.

The package description is:
 The motto of nn is its expanded name, which is "No News is good
 news, but nn is better", and the nn newsreader is designed to let you
 minimize the amount of time you spend reading news (or, more
 realistically, to allow you to follow even more newsgroups :-).
 .
 Nn allows you to quickly select articles of interest and skip the
 rest.  It also supports efficient article killing and selection of
 articles by author and subject.
 .
 This version of nn reads news from a news server via NNTP (the
 Network News Transfer Protocol), and can make use of your NNTP
 server's NOV database, if configured.  You must have a news server
 available - large sites usually provide a site-wide server.  (For
 those familiar with 'nn', this is a client-only version.)



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

Bug#470188: RFH: milter-greylist -- GreyList milter for sendmail

[Cord Beermann]

Package: wnpp
Severity: normal

I request assistance with maintaining the milter-greylist package.

The package description is:
 milter-greylist is a stand-alone milter written in C that implements the
 greylist filtering method, as proposed by Evan Harris.
 .
 Grey listing works by assuming that unlike legitimate MTA, spam engines will
 not retry sending their junk mail on a temporary error. The filter will
 always temporarily reject mail on a first attempt, and to accept it after
 some time has elapsed.
 .
 If spammers ever try to resend rejected messages, we can assume they will not
 stay idle between the two sends (if they do, the spam problem would just be
 solved). Odds are good that the spammer will send a mail to an honey pot
 address and get blacklisted in several real-time distributed black list
 before the second attempt.



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

Re: dpkg semi-hijack - an announcement (also, triggers)

[Roger Leigh]

On Sun, Mar 09, 2008 at 11:28:13AM +, Ian Jackson wrote:
> 
> [1] Guillem persistently reintroducing errors, wholesale
> 
> Here is an example of a big code change made by Guillem:
>   
> http://git.debian.org/?p=dpkg/dpkg.git;a=commit;h=4e5846ccd3dcc33504aba8ef35a8962bccfd562e
> However this is wrong as I explained here:
>   http://lists.debian.org/debian-dpkg/2007/10/msg00200.html

OK, you are correct here, but (char *) NULL would be clearer overall.

> I also emailed Guillem privately in August 2007 to ask that he stop
> this kind of thing.
> 
> Guillem has persisted with exactly the same mistake.  For example:
>   
> http://git.debian.org/?p=dpkg/dpkg.git;a=commit;h=02680ecbbbf6da2b023891a11b38ecce5346dbbd
> 
> It is one thing to make a coding mistake.  Everyone makes mistakes.
> It is quite another to make a widespread change, without discussion,
> and which is even if it is correct and worthwhile only at best
> stylistically helpful.  And then, after having been told that it was
> wrong, to continue requires a dogmatic belief in one's own
> correctness.

Here, either make sense in C99.  NULL does give slightly more context
than 0 however, so there's nothing technically wrong with the change,
even if your preferred style is to use 0.

I seriously can't believe that you hijacked this over a disagreement
about the definition/usage of NULL.  Include  and be done
with it already--it's not like this is a pressing or difficult problem
that warranted this action!


-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linux http://people.debian.org/~rleigh/
 `. `'   Printing on GNU/Linux?   http://gutenprint.sourceforge.net/
   `-GPG Public Key: 0x25BFB848   Please GPG sign your mail.


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

Re: dpkg semi-hijack - an announcement (also, triggers)

[William Pitcock]

On Sun, 2008-03-09 at 20:38 +0100, Raphael Hertzog wrote:
> And what is the problem exactly? The delay in patch integration?

A six month delay is unacceptable for code review. If it takes six
months, then new leadership is clearly required.

William


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

Re: dpkg semi-hijack - an announcement (also, triggers)

[Mike Bird]

On Sun March 9 2008 13:44:08 Roger Leigh wrote:
> I seriously can't believe that you hijacked this over a disagreement
> about the definition/usage of NULL.  Include  and be done
> with it already--it's not like this is a pressing or difficult problem
> that warranted this action!

Roger,

NULL is just a minor distraction.

Ian hijacked his own program back from the people who had been blocking
updates for six months - including the triggers enhancement which is
needed for boot time improvements and which should simplify some other
packaging issues.  This is not some hairy untested update - it has been
working well in Ubuntu for a long time.  There is no good reason why
Debian is lagging Ubuntu by six months on our own packaging tool.

The excuse given by the somewhat less than stellar dpkg team is that they
need more time to understand the changes.  If you look at the changes in
git you'll see they are not small but neither are they particularly large,
and that they are clear and even documented.  There's nothing there that
should have taken more than a couple of days to review.  By blocking
functionality for six months the old dpkg team has actively harmed Debian.

Yet another distraction raised by the dpkg blocking team is that they want
Ian to rebase.  They insist it is their team policy, but when asked they
point to a policy that recommends that the developer choose whether to
rebase and gives no role to other team members in deciding whether the
developer should rebase.  Raphael has been given ample opportunity to post
a link to a different policy or to retract his claims.  He has chosen to
do neither, which for me personally means I can no longer trust Raphael.

Now Anthony Towns has leapt in with both feet and handed dpkg back to the
obstructionists.  If Anthony has posted an explanation I have not seen
it.  You will recall Anthony - he alienated many Debian developers with
the Dunk-Tank fiaco and thereby significantly delayed the release of Etch.
This apparently makes Anthony a natural ally of the dpkg blocking team.

--Mike Bird


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

Re: dpkg semi-hijack - an announcement (also, triggers)

[Cyril Brulebois]

On 09/03/2008, Mike Bird wrote:
> Ian hijacked his own program back from the people who had been
> blocking updates for six months - including the triggers enhancement
> which is needed for boot time improvements

Is dpkg handling the boot sequence? Or are you confusing that with
dependency-based initscripts?

-- 
Cyril Brulebois


pgpO4ipOJOweh.pgp
Description: PGP signature

Re: dpkg semi-hijack - an announcement (also, triggers)

[William Pitcock]

Hi,

On Sun, 2008-03-09 at 13:19 -0800, Mike Bird wrote:
> including the triggers enhancement which is
> needed for boot time improvements and which should simplify some other
> packaging issues.

I think you mean package install-time improvements, due to postponing
ldconfig until the end of the installation. However, I am not sure how
useful this is because many maintainer scripts not generated by
debhelper call ldconfig locally.

Obviously the maintainer scripts autogenerated by debhelper would be ok
though.

William


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

Re: dpkg semi-hijack - an announcement (also, triggers)

[Aurelien Jarno]

William Pitcock a écrit :
> Hi,
> 
> On Sun, 2008-03-09 at 13:19 -0800, Mike Bird wrote:
>> including the triggers enhancement which is
>> needed for boot time improvements and which should simplify some other
>> packaging issues.
> 
> I think you mean package install-time improvements, due to postponing
> ldconfig until the end of the installation. However, I am not sure how
> useful this is because many maintainer scripts not generated by
> debhelper call ldconfig locally.

There is no need to delay calls to ldconfig anymore. Upstream has added
a secondary cache system in glibc 2.7, which make calls to ldconfig very
cheap when no changes to the libraries have been done.

Moreover as explained in the bug report, there are some concerns in
delaying all calls to ldconfig, as they may cause some problems for
libraries that are not in the standard search path, but defined in
/etc/ld.so.conf.

-- 
  .''`.  Aurelien Jarno | GPG: 1024D/F1BCDB73
 : :' :  Debian developer   | Electrical Engineer
 `. `'   [EMAIL PROTECTED] | [EMAIL PROTECTED]
   `-people.debian.org/~aurel32 | www.aurel32.net


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

Re: dpkg semi-hijack - an announcement (also, triggers)

[Joey Hess]

William Pitcock wrote:
> On Sun, 2008-03-09 at 20:38 +0100, Raphael Hertzog wrote:
> > And what is the problem exactly? The delay in patch integration?

If you'd look at submitting patches to dpkg from the perspective of any
recent patch submitter, I'd think that the problem would be clear.

-- 
see shy jo


signature.asc
Description: Digital signature

Re: dpkg semi-hijack - an announcement (also, triggers)

[Joey Hess]

William Pitcock wrote:
> I think you mean package install-time improvements, due to postponing
> ldconfig until the end of the installation. However, I am not sure how
> useful this is because many maintainer scripts not generated by
> debhelper call ldconfig locally.
> 
> Obviously the maintainer scripts autogenerated by debhelper would be ok
> though.

Triggers, if they ever reach the archive, should allow a vast improvement
in the majority of maintainer script fragments inserted by debhelper,
and in the simplicity, correctness, and speed of package installations.

-- 
see shy jo


signature.asc
Description: Digital signature

Re: dpkg semi-hijack - an announcement (also, triggers)

[Mike Bird]

On Sun March 9 2008 14:46:50 Cyril Brulebois wrote:
> On 09/03/2008, Mike Bird wrote:
> > Ian hijacked his own program back from the people who had been
> > blocking updates for six months - including the triggers enhancement
> > which is needed for boot time improvements
>
> Is dpkg handling the boot sequence? Or are you confusing that with
> dependency-based initscripts?

I hope I'm not mis-stating Frans's position when I say that Frans
believes dpkg triggers are the best way to install dependency-based
initscripts[0].  Otherwise the installer unnecessarily and repetitively
globally recalculates initscript dependencies for each package installed.

I expect dpkg triggers would also be valuable for things like mktexlsr
runs when working with texlive.

--Mike Bird

[0] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=465587#35


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

Re: Bits from the Security Team

[Noah Meyerhans]

On Sun, Mar 09, 2008 at 11:05:11PM +0100, Moritz Muehlenhoff wrote:
> * You need to be familiar with how the wide variety Debian packages
>   are maintained, patched and built. If you're not scared by
>   packages generating their patch series by applying sed statements
>   from cdbs include files before passing the patches through an
>   awk filter to quilt until they're finally built with yada, you
>   might be the right person.

OTOH, if you're doing that in one of *your* packages, you're probably
not the right person.  The security team prefers its members to be sane.
;)

noah



signature.asc
Description: Digital signature

debimg 0.0.1 released

[Julian Andres Klode]

Dear readers,

The first release of debimg is available now: 0.0.1

Get the tarball: http://users.alioth.debian.org/~jak-guest/debimg_0.0.1.tar.gz
Clone git repo:  git://git.debian.org/git/users/jak-guest/debimg.git
Browse the repo: http://git.debian.org/?p=users/jak-guest/debimg.git

This is the first release on the way to debimg 0.1, a new software developed by
me, and designed to replace debian-cd.

There are no packages yet, but 0.1 will be packaged. The code is just not
working yet in a packaged form.

The next release, 0.0.2, should follow in the next days. It will cleanup and
freeze the format of debimg.cfg for the 0.1 release.

For further information, see http://wiki.debian.org/debimg or the project page
at jak-linux.org: http://jak-linux.org/projects/debimg/

There is also a server providing daily-built netinst images of testing at
http://jak-linux.org/cdimage/daily-builds/ - they can be downloaded using Jigdo.

I do not plan to release many 0.0.x releases, as my goal is to release 0.1 this
month.

-- 
Julian Andres Klode, Fellow of the Free Software Foundation Europe
 Debian Maintainer | Developer | Ubuntu Member

try Debian: http://www.debian.org/ | my site: http://jak-linux.org/
jabber: [EMAIL PROTECTED] | IRC: juliank (FreeNode, OFTC)
languages: German  | English



signature.asc
Description: OpenPGP digital signature

Bug#470212: ITP: debimg -- replacement for debian-cd written in Python

[Julian Andres Klode]

Package: wnpp
Severity: wishlist
Owner: Julian Andres Klode <[EMAIL PROTECTED]>

* Package name: debimg
  Version : 0.1
  Upstream Author : Julian Andres Klode
* URL : http://wiki.debian.org/debimg
* License : GPL-3+
  Programming Lang: Python
  Description : replacement for debian-cd written in Python

debimg is a new alternative to debian-cd. It is not finished yet,
but the first release (0.0.1) has been released already.

For further information, you should visit the wiki page (see above)
or read the announcements on the debian-cd mailing list.


signature.asc
Description: Digital signature

Re: DD in Antarctic Continent?

[Adam Majer]

Roberto C. Sánchez wrote:
> On Sun, Mar 09, 2008 at 02:17:04PM -0400, Clint Adams wrote:
>> On Sun, Mar 09, 2008 at 05:13:14PM +0100, Lionel Elie Mamane wrote:
>>> So he's really in very-northern Finland/Sweden/Norway/Russia?
>> If I recall correctly, he was somewhere in or around Michigan.
>>
> Which really is not all that different from very-northern
> Finland/Sweden/Norway/Russia :-)

If state like Michigan is far north, then where is Canada?? :)

To put it in perspective, Michigan is at the same latitude as northern
half of Italy or even Spain. I would not say these are the northern tip
of Europe...

Most of Canadians live south of the latitude of London, UK.

- Adam


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

Re: dpkg semi-hijack - an announcement (also, triggers)

[Adam Borowski]

On Sun, Mar 09, 2008 at 02:17:15PM -0800, Mike Bird wrote:
> On Sun March 9 2008 14:46:50 Cyril Brulebois wrote:
> > Is dpkg handling the boot sequence? Or are you confusing that with
> > dependency-based initscripts?
> 
> I hope I'm not mis-stating Frans's position when I say that Frans
> believes dpkg triggers are the best way to install dependency-based
> initscripts[0].  Otherwise the installer unnecessarily and repetitively
> globally recalculates initscript dependencies for each package installed.
> 
> I expect dpkg triggers would also be valuable for things like mktexlsr
> runs when working with texlive.

AOL.  Try installing anything tex-related on a slow or mid-speed machine. 

So, what about leaving the bikeshed painted in Ian's color, and starting
from that point?  There are two strong technical arguments: 1. triggers
being a vital piece, and 2. diverging from Ubuntu is badly counter-
productive.

And then you can duke it out about NULL vs (char*)0 to your heart's content.

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


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

Re: dpkg semi-hijack - an announcement (also, triggers)

[Marc 'HE' Brockschmidt]

Mike Bird <[EMAIL PROTECTED]> writes:
> Ian hijacked his own program back from the people who had been blocking
> updates for six months - including the triggers enhancement which is
> needed for boot time improvements 

dpkg triggers are nice to have, but they are not the reason why we
haven't switched to a dependency-based init system yet. Please try to
only refer to issues you have fully understood.

Marc
-- 
BOFH #389:
/dev/clue was linked to /dev/null


pgpTBgriEu3BK.pgp
Description: PGP signature

Re: dpkg semi-hijack - an announcement (also, triggers)

[Michael Casadevall]

I'm going to have to agree with this; I admin m68k buildds; I had to 
preinstall most of the texex packages simply because it was taking hours 
(and that is not an exaggeration) to install them all, and then remove 
them all again. A trigger based system would help relieve this problem. I 
had a similar slowdown installing texex packages on a slower powerpc


That being said, I neither agree nor disagree with the hijacking of dpkg, 
but triggers are important, especially for slower architectures.

Michael

On Mon, 10 Mar 2008, Adam Borowski wrote:


Date: Mon, 10 Mar 2008 00:07:15 +0100
From: Adam Borowski <[EMAIL PROTECTED]>
To: debian-devel@lists.debian.org
Subject: Re: dpkg semi-hijack - an announcement (also, triggers)
Resent-Date: Sun,  9 Mar 2008 23:11:16 + (UTC)
Resent-From: debian-devel@lists.debian.org

On Sun, Mar 09, 2008 at 02:17:15PM -0800, Mike Bird wrote:

On Sun March 9 2008 14:46:50 Cyril Brulebois wrote:

Is dpkg handling the boot sequence? Or are you confusing that with
dependency-based initscripts?


I hope I'm not mis-stating Frans's position when I say that Frans
believes dpkg triggers are the best way to install dependency-based
initscripts[0].  Otherwise the installer unnecessarily and repetitively
globally recalculates initscript dependencies for each package installed.

I expect dpkg triggers would also be valuable for things like mktexlsr
runs when working with texlive.


AOL.  Try installing anything tex-related on a slow or mid-speed machine.

So, what about leaving the bikeshed painted in Ian's color, and starting
from that point?  There are two strong technical arguments: 1. triggers
being a vital piece, and 2. diverging from Ubuntu is badly counter-
productive.

And then you can duke it out about NULL vs (char*)0 to your heart's content.

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


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




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

Re: DD in Antarctic Continent?

[John Hasler]

Adam writes:
> To put it in perspective, Michigan is at the same latitude as northern
> half of Italy or even Spain.

Michigan extends from about 42N to about 48N: about from Rome to Munich.

> Most of Canadians live south of the latitude of London, UK.

A fact which caused considerable consternation among early North American
colonists when their first winter arrived.
-- 
John Hasler


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

Re: dpkg semi-hijack - an announcement (also, triggers)

[Mike Bird]

On Sun March 9 2008 16:07:58 Marc 'HE' Brockschmidt wrote:
> Mike Bird <[EMAIL PROTECTED]> writes:
> > Ian hijacked his own program back from the people who had been blocking
> > updates for six months - including the triggers enhancement which is
> > needed for boot time improvements
>
> dpkg triggers are nice to have, but they are not the reason why we
> haven't switched to a dependency-based init system yet. Please try to
> only refer to issues you have fully understood.

Marc,

A necessary condition is not the same as a sufficient condition.

Triggers are "needed" - a necessary condition, or at least a highly
desirable condition - for efficient installation of packages in order
to avoid unnecessary repetitive global reorderings of the initscript
dependency DAG as each package is installed.

"The reason why we haven't switched yet" does not exist, as there
are several reasons not one, but if a single reason did exist it
would have been a sufficient condition, not a necessary condition.

In simple terms: "dpkg triggers" is a highly desirable precondition for
dependency-based initscripts, but so are several other preconditions,
not least of which is a substantial test period.  The issues are
well addressed in Frans' posting, the URL of which I have already
posted once in this thread and will now post again[0].

I believe it was you who wrote "Please try to only refer to issues
you have fully understood."

--Mike Bird

[0] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=465587#35


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

Re: DD in Antarctic Continent?

[Roberto C . Sánchez]

On Sun, Mar 09, 2008 at 05:21:19PM -0500, Adam Majer wrote:
> Roberto C. Sánchez wrote:
> > On Sun, Mar 09, 2008 at 02:17:04PM -0400, Clint Adams wrote:
> >> On Sun, Mar 09, 2008 at 05:13:14PM +0100, Lionel Elie Mamane wrote:
> >>> So he's really in very-northern Finland/Sweden/Norway/Russia?
> >> If I recall correctly, he was somewhere in or around Michigan.
> >>
> > Which really is not all that different from very-northern
> > Finland/Sweden/Norway/Russia :-)
> 
> If state like Michigan is far north, then where is Canada?? :)
> 
> To put it in perspective, Michigan is at the same latitude as northern
> half of Italy or even Spain. I would not say these are the northern tip
> of Europe...
> 
Well, I am from Florida.  Any temperature below 50F is too cold as far
as I am concerned :-)

Regards,

-Roberto

-- 
Roberto C. Sánchez
http://people.connexer.com/~roberto
http://www.connexer.com


signature.asc
Description: Digital signature

Re: dpkg semi-hijack - an announcement (also, triggers)

[Daniel Stone]

[Not subscribed, Cc if you want me to see it.]

On Sun, Mar 09, 2008 at 01:19:58PM -0800, Mike Bird wrote:
> Ian hijacked his own program back from the people who had been blocking
> updates for six months

So Ian Murdock would be perfectly entitled to kick out the DAM, DPL, TC,
DSA, and all others to really fix Debian?

> including the triggers enhancement which is needed for boot time
> improvements

No, it isn't (better documented by other replies).

> By blocking
> functionality for six months the old dpkg team has actively harmed Debian.

I was going to ask on which grounds exactly you were judging the dpkg
team's competence (and that of iwj's: have you reviewed the branch
yourself? can you confidently say that it's all fine?), but instead I'll
ask this: How have you helped Debian in the last six months, if the dpkg
team has actively harmed it for the last six?

> He has chosen to
> do neither, which for me personally means I can no longer trust Raphael.

Tragedy.

Daniel


signature.asc
Description: Digital signature

Timeline for normal buildd operation on MIPS ?

[Charles Plessy]

Dear MIPS porters,

Despite the hard work you made for your buildds, the backlog is stil
stabilizing to a level that blocks into unstable the packages that
evolve at the periphery of the Debian galaxy, such as scientific
applications.

In order to help the people maintaining such packages to orgainze
themselves, can you publish a timeline of your works and goals for the
MIPS infrastructure? It has been more than three months that the backlog
is there; this is more than half the time left before the freeze.

Please be assured of the sympathy I have for your project,

-- 
Charles Plessy
Debian-Med packaging team,
Wakō, Saitama, Japan


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

Re: Timeline for normal buildd operation on MIPS ?

[Cyril Brulebois]

On 10/03/2008, Charles Plessy wrote:
> Dear MIPS porters,

Dear Charles,

> Despite the hard work you made for your buildds, the backlog is stil
> stabilizing to a level that blocks into unstable the packages that
> evolve at the periphery of the Debian galaxy, such as scientific
> applications.

despite the words you're trying to use to mask it, you're really
harrassing them for no valid reasons.

> In order to help the people maintaining such packages to organize
> themselves, can you publish a timeline of your works and goals for the
> MIPS infrastructure? It has been more than three months that the
> backlog is there; this is more than half the time left before the
> freeze.

In order to keep the noise on this (these) list(s) at a suitable level,
can you please stop that? It's been more than three weeks that you're
ranting.

> Please be assured of the sympathy I have for your project,

Please be assured of the sympathy I have for your trying to have your
packages into testing at all costs,

-- 
Cyril Brulebois


pgpZwLabADZMj.pgp
Description: PGP signature

Re: dpkg semi-hijack - an announcement (also, triggers)

[Anthony Towns]

On Sun, Mar 09, 2008 at 07:52:28PM +0100, Raphael Hertzog wrote:
> On Sun, 09 Mar 2008, Raphael Hertzog wrote:
> > On Sun, 09 Mar 2008, Ian Jackson wrote:
> > > With this message I am unilaterally declaring myself a maintainer of
> > > dpkg, and also declaring that Guillem is no longer a maintainer.
> > For the record, Ian has been removed from the "dpkg" group on Alioth and
> > we asked for an UNACCEPT of his upload, but I'm not sure it will be done
> > on time as none of the ftpmasters responded yet to my queries on IRC.
> The package got unaccepted by Anthony Towns.

Beyond that, any additional uploads of dpkg will be REJECTed until you
guys resolve this nonsense. Flamewars on -devel, ignoring functional
patches for months on end, package hijacks and requests for UNACCEPTs
aren't the way to maintain dpkg.

Cheers,
aj



signature.asc
Description: Digital signature

Re: dpkg semi-hijack - an announcement (also, triggers)

[Marc 'HE' Brockschmidt]

[Not CCing -dpkg anymore, not relevant there]

Mike Bird <[EMAIL PROTECTED]> writes:
> Triggers are "needed" - a necessary condition, or at least a highly
> desirable condition - for efficient installation of packages in order
> to avoid unnecessary repetitive global reorderings of the initscript
> dependency DAG as each package is installed.

No. They would be nice, nothing more.

> "The reason why we haven't switched yet" does not exist, as there
> are several reasons not one, but if a single reason did exist it
> would have been a sufficient condition, not a necessary condition.
>
> In simple terms: "dpkg triggers" is a highly desirable precondition for
> dependency-based initscripts, but so are several other preconditions,
> not least of which is a substantial test period.  The issues are
> well addressed in Frans' posting, the URL of which I have already
> posted once in this thread and will now post again[0].

You seem to believe that Frans decides if and when we are going to
switch to a dep-based init system. That is not the case. The release
team will decide together with the involved package maintainers if this
is a feature that can reasonably be enabled for lenny [1]. At this
point, the main problem is that there is not enough experience with the
system, it misses broad testing and that there are still heaps of
packages around which ship init scripts without dependency information.

Oh, and fuck you too for the "in simple terms". At this point I would
love to hear who you are and why you parade around -devel, giving the
impression to be better informed about the preconditions for transitions
than the people actually in charge.

Marc

Footnotes: 
[1]  Either as default for all system or only for fresh installs.
-- 
BOFH #429:
Temporal anomaly


pgpXQcQYiblfr.pgp
Description: PGP signature

Re: dpkg semi-hijack - an announcement (also, triggers)

[Mike Bird]

On Sun March 9 2008 17:30:51 Daniel Stone wrote:
> [Not subscribed, Cc if you want me to see it.]
>
> On Sun, Mar 09, 2008 at 01:19:58PM -0800, Mike Bird wrote:
> > Ian hijacked his own program back from the people who had been blocking
> > updates for six months
>
> So Ian Murdock would be perfectly entitled to kick out the DAM, DPL, TC,
> DSA, and all others to really fix Debian?

I think it unlikely that the DAM, DPL, TC, and DSA would block useful
updates to Debian for six months while they tried to learn C.  Your
question is a remote hypothetical.  However, in that unlikely event,
I would certainly support Ian Murdock if he hijacked Debian to fix it.

--Mike Bird


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

Re: dpkg semi-hijack - an announcement (also, triggers)

[Sune Vuorela]

On 2008-03-10, Mike Bird <[EMAIL PROTECTED]> wrote:
> I think it unlikely that the DAM, DPL, TC, and DSA would block useful
> updates to Debian for six months

Welcome to real world.

/Sune


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

Re: dpkg semi-hijack - an announcement (also, triggers)

[Mike Bird]

On Sun March 9 2008 18:40:25 Marc 'HE' Brockschmidt wrote:
> Mike Bird <[EMAIL PROTECTED]> writes:
> > In simple terms: "dpkg triggers" is a highly desirable precondition for
> > dependency-based initscripts, but so are several other preconditions,
> > not least of which is a substantial test period.  The issues are
> > well addressed in Frans' posting, the URL of which I have already
> > posted once in this thread and will now post again[0].
>
> You seem to believe that Frans decides if and when we are going to
> switch to a dep-based init system.

Your English is much better than my German.  Nevertheless either your
English is inadequate for the role you are attempting to fill or else
you are deliberately trying to provoke an argument.

I said that "the issues are well addressed in Frans' posting".  That
is not an assertion that Frans decides if and when Debian will switch.

> Oh, and fuck you too for the "in simple terms".

Auf Wiederlesen,

--Mike Bird


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

NULL and (char *) 0 (was: dpkg semi-hijack - an announcement (also, triggers))

[Russ Allbery]

Riku Voipio <[EMAIL PROTECTED]> writes:
> On Sun, Mar 09, 2008 at 06:34:36PM +, Ian Jackson wrote:
>> Pierre Habouzit writes:

>>>   If you're so afraid that one of the included headers defines NULL to
>>> '0', then just assert (__builtin_types_compatible(NULL, void *))
>>> somewhere and be done with it. But please, (char *)0 is not only wrong,
>>> it's also tasteless and ugly to the eye.

>> In what way is (char*)0 wrong in these contexts ?

> According to execlp manpage:
>
>   The list of arguments must be terminated by a NULL pointer,
>   and, since these are vari‐adic functions, this pointer _must_
>   be cast (char *) NULL.

(char *) NULL is completely equivalent to (char *) 0 in C.

Ian is entirely correct from the standpoint of C standards pedanticism.
Either 0 or NULL is a valid null pointer constant in any context in which
a pointer is expected, and in variadic functions, using NULL is not safe.
Even apart from the fact that NULL is permitted to be defined to 0, and
hence not a pointer in a variadic context, the C standard does not require
that all pointers be the same.  (void *) 0 is permitted to be a different
bit pattern than (int *) 0 and neither is required to be an all-zero bit
pattern.  In order to be entirely correct, you must cast a NULL pointer
constant passed to a variadic function to exactly the type of pointer that
the function expects, whether that be char *, int *, or something else.
Using NULL, or even always using (char *) 0 without regard for what's
expected, is not correct.

It's fairly unlikely that any of this would result in noticable bugs on
the systems to which Debian has been ported, given that gcc defines NULL
to ((void *) 0) and none of the systems on which Debian runs use different
bit patterns for null pointer constants for different types of constants
(and doing so would break a lot of code written with less detailed
attention to the standard).

Usually people don't worry about this (and make other similar assumptions,
like assuming that you can initialize a structure containing pointers with
calloc and get null pointers).  I try not to, when I remember, but given
the paucity of systems on which these assumptions break, most C code that
you see is not this careful.

This topic is a whole *section* in C FAQ, BTW.  See:

http://c-faq.com/null/index.html

-- 
Russ Allbery ([EMAIL PROTECTED])   

Re: dpkg semi-hijack - an announcement (also, triggers)

[Steve Greenland]

On 09-Mar-08, 19:30 (CDT), Daniel Stone <[EMAIL PROTECTED]> wrote: 
> I was going to ask on which grounds exactly you were judging the dpkg
> team's competence (and that of iwj's: have you reviewed the branch
> yourself? can you confidently say that it's all fine?),

The problem is not the dpkg team has reviewed the patch and had problems
with it, it's that they've ignored it for 6 months.

I don't approve of IanJ's hijack attempt, but in this he's got a
legitimate complaint. So do the rest of us who've been waiting for
triggers for *years*.

Steve

-- 
Steve Greenland
The irony is that Bill Gates claims to be making a stable operating
system and Linus Torvalds claims to be trying to take over the
world.   -- seen on the net


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

Re: dpkg semi-hijack - an announcement (also, triggers)

[Anthony Towns]

On Sun, Mar 09, 2008 at 10:38:44PM -0500, Steve Greenland wrote:
> On 09-Mar-08, 19:30 (CDT), Daniel Stone <[EMAIL PROTECTED]> wrote: 
> > I was going to ask on which grounds exactly you were judging the dpkg
> > team's competence (and that of iwj's: have you reviewed the branch
> > yourself? can you confidently say that it's all fine?),
> The problem is not the dpkg team has reviewed the patch and had problems
> with it, it's that they've ignored it for 6 months.

That's not the full picture. 

Ian's been trying to be involved in the dpkg team for longer than six
months, and not been incredibly effective at that; eg from July:

   I will of course be careful about controversial changes.  For example,
   I'll refrain from committing my formatting fixup from #375711 until
   we've come to a conclusion.  I hope you can trust my judgement about
   what would be a controversial change.

   -- http://lists.debian.org/debian-dpkg/2007/07/msg00013.html 

Ian then reposted the triggers spec and published a git tree for the patch,
with the following comment:

   I'd appreciate it if no-one reformatted it or change the style.  If
   you have disagreements with the code please discuss it here on the
   list before making any changes.  Checking a significantly changed
   version into the main Debian git will cause snarl-ups because our
   merges will constantly need resolving.

   -- http://lists.debian.org/debian-dpkg/2007/08/msg00014.html
   -- http://lists.debian.org/debian-dpkg/2007/08/msg9.html

Ian then reimplemented the status file parsing using flex, in a way he
reported was faster, but hadn't tested, and suggested it get included in
sid.

   I have written over the weekend a replacement for lib/fields.c and
   most of lib/parse.c, which uses flex (and flex start conditions) to
   generate a table-driven scanner-cum-parser.  I haven't tested this
   fully for correctness yet, but I have done basic functionality tests
   and some performance tests.

   ...

   The downside is that it's 100K longer in code size. ...

   Anyway, I think we should deploy the flex-based scanner in sid (after
   I've tested it a bit more) and then think at our leisure about how to
   improve the shared code situation.

   -- http://lists.debian.org/debian-dpkg/2007/08/msg00028.html

Guillem replied to that patch within about four days, but the git tree
Ian developed it in was based on the triggers tree, so can't be easily
merged independently.

In October, Joey proposed his v3 source package format, which is one of
the other major outstanding patches. I don't believe it has any stylistic
problems, but it still seems to be being reinvented/redisgned, rather than
being applied.

   -- http://lists.debian.org/debian-dpkg/2007/10/msg9.html
   -- http://lists.debian.org/debian-dpkg/2008/02/msg00012.html
  http://lists.debian.org/debian-dpkg/2008/02/msg00079.html
  http://lists.debian.org/debian-dpkg/2008/02/msg00131.html

Also in October, Colin Watson asked what the status of triggers was. Ian
replied:

   The implementation of triggers is not going to change incompatibly.
   It's well-tested now in Ubuntu and should just be merged into Debian's
   dpkg.

   -- http://lists.debian.org/debian-dpkg/2007/10/msg00107.html

Guillem replied to that:

   Err, well of course it's highly desirable to not do such kind of
   changes without good reason, but I don't think the fact that it has been
   deployed in a derivative distro means that we should blindly merge any
   such code drops without review and/or possible changes.

   -- http://lists.debian.org/debian-dpkg/2007/10/msg00132.html

Ian replied to that:

   Don't be ridiculous.  This is offensive to me personally.

   This code has been
* designed with extensive input from this mailing list in Debian fora
* written by dpkg's original maintainer
* tested extensively
* available for merging for several months

   -- http://lists.debian.org/debian-dpkg/2007/10/msg00138.html

Guillem didn't reply to that; his next comment on triggers a couple of weeks
later was, in response to Ian:

   > This isn't a matter of preference, I'm afraid.  I reverted this
   > because the change was wrong.  NULL is incorrect in that context (a
   > stdarg function expecting a char*), because it may be #define'd to 0.

   That's true, but then I agree with others [0] that an environment that
   defines NULL to 0 (even if the standard allows that) is not sane. Such
   ancient environment will also not be able to cope with modern software
   like gtk, anyway.

   [0] http://lwn.net/Articles/93577/

   -- http://lists.debian.org/debian-dpkg/2007/10/msg00228.html

There were a couple of messages that sounded promising in regards to a
productive conclusion at the end of that month:

   -- http://lists.debian.org/debian-dpkg/2007/10/msg00230.html
   -- http://lists.debian.org/debian-dpkg/2007/10/msg00231.html

Nothing much happened in Nov or Dec; both Ian and Guillem posted about
random oth

Bug#470236: RFP: flam3 -- Programs to generate and render cosmic recursive fractal flames (fwd)

[Ian Weller]

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

Package name: flam3
Version: 2.7.9
Upstream author: Scott Draves 
URL: http://www.flam3.com/
License: GPLv2+
Description: Flam3, or Fractal Flames, are algorithmically generated images and 
animations. This is free software to render fractal flames as described on 
http://flam3.com. Flam3-animate makes animations, and flam3-render makes still 
images. Flam3-genome creates and manipulates genomes (parameter sets).


I've already packaged this for Fedora and Scott is asking me to look for a 
maintainer for Debian.  The specfile and patches used by Fedora are available 
at http://cvs.fedoraproject.org/viewcvs/rpms/flam3/ .




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

Dependency based boot sequencing and triggers (Was: dpkg semi-hijack - an announcement (also, triggers))

[Petter Reinholdtsen]

[Mike Bird]
> I hope I'm not mis-stating Frans's position when I say that Frans
> believes dpkg triggers are the best way to install dependency-based
> initscripts[0].

I believe your understanding of Frans' position is fairly correct, but
it differ from mine, and I am the one behind the dependency boot
sequencing proposal.  I am not convinced yet that triggers are needed,
nor wanted, for dependency boot sequencing.  This is partly because I
believe the failure modes Frans mention in his post are unlikely to
happen (or impossible, but it is harder to prove).

So those of you wanting to test dependency based boot sequencing do
not have to wait for triggers for it to work properly.  80% of the
packages got the dependency headers already, and those already using
it report that it work quite well. :)

More information on the feature is available from
http://wiki.debian.org/LSBInitScripts/DependencyBasedBoot>.

> Otherwise the installer unnecessarily and repetitively globally
> recalculates initscript dependencies for each package installed.

Actually, it happens every time a init.d script is added to the boot
and shutdown sequence, and I believe it have to do that, to make sure
each script insertion fail individually when a script with incorrect
dependency information is encountered.

I will have to learn more about triggers before I make up my mind,
though.

Happy hacking,
-- 
Petter Reinholdtsen


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