Re: Transition from dpkg to GNU install-info

[Guillem Jover]

On Fri, 2009-03-13 at 19:07:12 +0100, Raphael Hertzog wrote:
> On Fri, 13 Mar 2009, Norbert Preining wrote:
> I just wrote it. I had to do it in C otherwise I couldn't do the check
> on how it's called.

Cool!

> > Why? What would change? info-browsers (see below) should depend on
> > install-info, but if they don't well, then we file a bug to fix that.
> > But we should have install-info first in sid.
> 
> When we upload dpkg to sid, if it contains the Breaks dep,
> it will effectively break all info-browsers that have not been updated
> yet. It's best to avoid that if possible by doing the dpkg upload after
> the info-browsers update.

Yes.

> > Anyway, does that mean with the ok of more people here that after
> > testing dpkg (hopefully after the weekend with your patch) I should
> > upload to sid?
> 
> I guess so. Asking for review/test on -devel is certainly a good idea at
> this point.

Once we have hammered those last decisions, we should update the wiki
page and send something like what Norbert proposed to -devel. Probably
add also an item to the DeveloperNews.

Some minor comments, the rest is on my previous mail about the
warnings on the other conditions:

>  debian/dpkg.install   |1 -
>  debian/dpkg.lintian-overrides |2 +
>  man/Makefile.am   |1 -
>  man/install-info.8|  295 ---
>  man/po/po4a.cfg   |5 -
>  po/POTFILES.in|1 -
>  scripts/Makefile.am   |   16 +--
>  scripts/install-info.pl   |  524 
> -

Missing removals in “scripts/.gitignore”.

>  utils/.gitignore  |1 +
>  utils/Makefile.am |   14 +-
>  utils/install-info.c  |   34 +++
>  11 files changed, 51 insertions(+), 843 deletions(-)

And there's an entry in the TODO list, you can remove it now.

> diff --git a/utils/.gitignore b/utils/.gitignore
> index bf5714e..ee8689b 100644
> --- a/utils/.gitignore
> +++ b/utils/.gitignore
> @@ -1 +1,2 @@
>  start-stop-daemon
> +install-info

A missing install-info-stamp.

> diff --git a/utils/Makefile.am b/utils/Makefile.am
> index cd1e4f1..2de2b0c 100644
> --- a/utils/Makefile.am
> +++ b/utils/Makefile.am
> @@ -6,7 +6,6 @@ INCLUDES = \
>   -idirafter $(top_srcdir)/libcompat \
>   -I$(top_srcdir)/lib
>  
> -

Spurious line removal. :)

>  if WITH_START_STOP_DAEMON
>sbin_PROGRAMS = start-stop-daemon
>  
> diff --git a/utils/install-info.c b/utils/install-info.c
> new file mode 100644
> index 000..ee8758b
> --- /dev/null
> +++ b/utils/install-info.c

Even if temporary, probably better to add a license header.

> @@ -0,0 +1,34 @@
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define WARN "install-info: warning: "
> +#define FAIL "install-info: failure: "
> +
> +int
> +main(int argc, char **argv)
> +{
> +if (strcmp(argv[0], "/usr/sbin/install-info") == 0) {
> + fprintf(stderr, WARN "/usr/sbin/install-info provided by "
> + "dpkg is deprecated\n");
> + fprintf(stderr, WARN "its replacement lives in /usr/bin/\n");
> +}
> +
> +if (access("/usr/bin/install-info", X_OK) == 0) {
> + execv("/usr/bin/install-info", argv);

Print an error message here as well.

> + return 1; /* exec failed */
> +} else {
> + if (errno == ENOENT) {
> + fprintf(stderr, WARN "nothing done since /usr/bin/install-info "
> + "doesn't exist\n");
> + } else {
> + fprintf(stderr, FAIL "can't execute /usr/bin/install-info: %s\n",
> + strerror(errno));
> + return 1;
> + }
> +}
> +
> +return 0;
> +}

regards,
guillem


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

sbuild version on buildd and bug 471747

[Raphael Hertzog]

Hello,

last year I reported
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=471747 against
sbuild and we hold off changing dpkg-source's output due to that
bug in the (neuro-maintained) sbuild used by buildd.

Now I scheduled the output change for dpkg 1.15.2 which will hit
unstable in the upcoming weeks (no precise schedule yet) because I thought
that the unreleased sbuild was no more in use.

Apparently I was wrong, only some buildd have been updated according to a
chat on #debian-buildd.

Do you know if those sbuild use the host dpkg-source or the chroot one?
In the former case, there's no problem, in the latter we should rather
revert unless you manage to roll out the update to all buildds in a
reasonable timeframe.

Please let us know what's the best course of action. If we have to revert
once more, I'd appreciate if you could ping us when it's safe to do the
change on our side.

Cheers,
-- 
Raphaël Hertzog

Contribuez à Debian et gagnez un cahier de l'admin Debian Lenny :
http://www.ouaza.com/wp/2009/03/02/contribuer-a-debian-gagner-un-livre/


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

Re: [RFC] [Cross Toolchain] Multiarch and sysrooted toolchain

[Goswin von Brederlow]

Hector Oron  writes:

> Hello,
>
>> The toolchain does not yet look in all the right places. Neither for
>> the multiarch nor the corss-compile way of putting the prefix. It is
>> in a state where both ways are used and neither is complete enough for
>> a full system.
>
> So, would it be fine to send an addendum to multiarch[1] document
> taking into account cross environments?
>
> In case, we write up that file, preferred way for cross environments
> would be a sysroot , where in multiarch do we fit our cross 
> ? Or we should just go for the splitted /* option (which won't be
> useful until multiarch is ready) ?

There is no cross , there is just . The aim for multiarch is
to have a unique place for every library for every target. As the
 is already unique there is no need to change it for cross
compiling purposes. The same dir will work for native and cross
purposes.

>>From cross toolchain point of view, i would suggest to stay with
> upstream maintainers layout, which would require a change on
> dpkg-cross, moving
> /include into /usr/include, that way we would be able to export 
> .

Would that mean moving /usr/include/x86_64-linux-gnu/ into
/usr/x86_64-linux-gnu/usr/include/x86_64-linux-gnu/?

Instead of moving you could just change the sysroot from
/usr/x86_64-linux-gnu to /.

And yes, for exporting it would mean exporting /lib/x86_64-linux-gnu,
/usr/lib/x86_64-linux-gnu and /usr/include/x86_64-linux-gnu.

> Regards
>
> [1] http://lackof.org/taggart/hacking/multiarch/

MfG
Goswin


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

Re: sbuild version on buildd and bug 471747

[Philipp Kern]

Hallo Raphael,

am Mon, Mar 16, 2009 at 09:58:21AM +0100 hast du folgendes geschrieben:
> Do you know if those sbuild use the host dpkg-source or the chroot one?

as far as I can see neuro's sbuild only does a chroot for dpkg-buildpackage
and some script invocations.

> In the former case, there's no problem, in the latter we should rather
> revert unless you manage to roll out the update to all buildds in a
> reasonable timeframe.

It will take some weeks still, for one because the new sbuild completely
changed its log format which will render it incompatible with the tools
the buildd admins use.

Kind regards,
Philipp Kern
-- 
 .''`.  Philipp KernDebian Developer
: :' :  http://philkern.de Release Assistant
`. `'   xmpp:p...@0x539.de Stable Release Manager
  `-finger pkern/k...@db.debian.org


signature.asc
Description: Digital signature

Re: Transition from dpkg to GNU install-info

[Raphael Hertzog]

Hi,

On Mon, 16 Mar 2009, Guillem Jover wrote:
> Actually, if called with an absolute path, the warning should ask the
> caller to not use such absolute path (maybe as a side note, explain
> the rationale, because it's generally wrong, and in this case because
> it will stop working if using /usr/sbin/).

Fine.

> > >   . if called and there is no /usr/bin/install-info give a big fat
> > > warning and die. Or?
> > 
> > Dying is not really an option. It might be legitimate that
> > /usr/bin/install-info is not here: because no info reader is installed.
> 
> Right. Also I guess when warning we want to distinguish here the case
> a maintainer script is calling us, which then we want to explain that
> they should stop doing so, as this is handled by triggers now. And the
> case a user is calling us which we'd recommend them installing at least
> the install-info package and maybe an info-browser. Otherwise as there's
> no /usr/bin/install-info we'll not be able to give accurate info.

I can add print this additionnal information in case there's no
/urs/bin/install-info and we have DPKG_RUNNING_VERSION set.

If we have /urs/bin/install-info, it will take care of printing the
message for us.

> > Note: if we really wanted, we could avoid that intermediary wrapper and
> > have it in dpkg but that would mean that the "install-info" interface is
> > deprecated and that user are expected to use ginstall-info in the long
> > term.
> 
> Well, I don't see why that'd be the case. The install-info package
> can always reclaim the correct path name in the future once we drop
> the wrapper from dpkg.

We want to avoid to have to coordinate once more for the final move.
It's best to avoid a system with install-info installed but without
install-info binary because dpkg was upgraded to a version that doesn't
provide it.

IOW, depending on install-info should be enough to ensure that
install-info exists in $PATH. This can only be true if /usr/bin/install-info is
part of install-info right from the beginning unless we want to add a
Breaks: install-info (< first-version-with-usr-bin-install-info) once
we remove the wrapper from dpkg.

I prefer to avoid the supplementary Breaks and handle everything now
without having to remember that we should add the Breaks once we remove
the wrapper.

What do you think ?

> Anyway I think I'd prefer only one install-info in /usr/sbin/, but would
> not mind the other one in /usr/bin/. In the latter case both should be
> mostly identical IMO, either hardlinks in dpkg, or the same source
> code duped in both packages (dpkg and install-info).

As long as the one in /usr/sbin/ always ends up calling the one in
/usr/bin I don't see what the problem is.

Having two different behaviour depending on the order in PATH would be
bad, but here we have a single behaviour since the one in /usr/bin gets to
dictate what's done and the other one is a wrapper. The fact that 
the install-info package decided to make it a wrapper too (as opposed to
"patch ginstall-info to have the desired behaviour") should not change
anything from our point of view.

A new version of the patch is in my branch, it should fix all the points you
have brought up (except the common wrapper thing):
http://git.debian.org/?p=users/hertzog/dpkg.git;a=commitdiff;hb=pu/install-info

Cheers,
-- 
Raphaël Hertzog

Contribuez à Debian et gagnez un cahier de l'admin Debian Lenny :
http://www.ouaza.com/wp/2009/03/02/contribuer-a-debian-gagner-un-livre/


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

Re: sbuild version on buildd and bug 471747

[Raphael Hertzog]

Hi,

On Mon, 16 Mar 2009, Philipp Kern wrote:
> am Mon, Mar 16, 2009 at 09:58:21AM +0100 hast du folgendes geschrieben:
> > Do you know if those sbuild use the host dpkg-source or the chroot one?
> 
> as far as I can see neuro's sbuild only does a chroot for dpkg-buildpackage
> and some script invocations.

So dpkg-source -x is done on the host and the change should not cause any
problem since only the dpkg-source in the chroot will change.

Thanks!

Cheers,
-- 
Raphaël Hertzog

Contribuez à Debian et gagnez un cahier de l'admin Debian Lenny :
http://www.ouaza.com/wp/2009/03/02/contribuer-a-debian-gagner-un-livre/


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

Re: Transition from dpkg to GNU install-info

[Norbert Preining]

Hi guys,

I am a bit lost ATM what *I* have to do at the moment?

On Mo, 16 Mär 2009, Raphael Hertzog wrote:
> dictate what's done and the other one is a wrapper. The fact that 
> the install-info package decided to make it a wrapper too (as opposed to
> "patch ginstall-info to have the desired behaviour") should not change
> anything from our point of view.

Yeah, because when we have fixed up dh_installinfo we can (in squeeze+1)
ship GNU install-info as /usr/bin/ and forget anything else.

Should I edit the proposal email I sent, or is one of you making other
changes, plus the ones suggested in the last emails?

for the wrapper in /usr/sbin and / or /usr/bin? Should we have a common
code base? In fact my /usr/bin/install-info currently is only:

if [ -z "$DPKG_RUNNING_VERSION" ] ; then
  # it seems we are running from outside a maintainer script, so give a
  # warning and call ginstall-info without anything else
  echo "This is not dpkg install-info anymore, but GNU install-info" >&2
  echo "See the man page for ginstall-info for command line arguments"
>&2
  ginstall-info "$@"
else 
  # we are running from a maintainer script, simply ignore the call
  # since we have trigger support and people should rebuild their
  # package with new debhelper which does not add calls to install-info
  echo "ignoring install-info called from maintainer script" >&2
  echo "this package should be rebuild with new debhelper to get trigger 
support" >&2
fi
-
which is really simple, maybe too simplistic. But we can iron things out
on the way.

Best wishes

Norbert

---
Dr. Norbert Preining Vienna University of Technology
Debian Developer  Debian TeX Group
gpg DSA: 0x09C5B094  fp: 14DF 2E6C 0307 BE6D AD76  A9C0 D2BF 4AA3 09C5 B094
---
ARAGLIN (n. archaic)
A medieval practical joke played by young squires on a knight aspirant
the afternoon he is due to start his vigil. As the knight arrives at
the castle the squires attempt to raise the drawbridge very suddenly
as the knight and his charger step on to it.
--- Douglas Adams, The Meaning of Liff


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

Re: Transition from dpkg to GNU install-info

[Norbert Preining]

On Mo, 16 Mär 2009, Nicolas François wrote:
> > - file bugs against all the info shipping packages with problematic info
> >   files
> 
> Maybe recommend that install-info should be called without options but the
> info files themselves should be updated.
> And --section shall be avoided (this is IIRC the most problematic option)

What about:
- file bugs against all the info shipping packages with problematic info
  files so that the --section argument to install-info is not needed
  anymore. postinst actions should not call install-info directly

> > Open questions:
> > - the file trigger should be mentioned in the policy
> > - review of update-info-dir script
> 
> I remember there could be some issue with emacs info files (because they
> are installed in sub-directories?)

I use find to find the info files, so that is not the problem. 

> I will try to review update-info-dir next week.

That would be great, please use the version from svn always, thanks.
http://svn.debian.org/wsvn/debian-tex/texinfo/branches/split-ii/debian/update-info-dir?op=file&rev=0&sc=0

(or any other prog for normal debian svn access to
debian-tex/texinfo/branches/split-ii/debian/update-info-dir
)

Thanks a lot and all the best

Norbert

---
Dr. Norbert Preining Vienna University of Technology
Debian Developer  Debian TeX Group
gpg DSA: 0x09C5B094  fp: 14DF 2E6C 0307 BE6D AD76  A9C0 D2BF 4AA3 09C5 B094
---
WORMELOW TUMP (n.)
Any seventeen-year-old who doesn't know about anything at all in the
world other than bicycle gears.
--- Douglas Adams, The Meaning of Liff


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

Re: Bug#487437: Please include /etc/dpkg/origins/{debian,default}

[Raphael Hertzog]

Hello Santiago,

On Wed, 27 Aug 2008, Raphael Hertzog wrote:
> On Wed, 27 Aug 2008, Santiago Vila wrote:
> > Sorry for not answering this before. Is this something that you would
> > like to see implemented in lenny?
> 
> It's not required for lenny. The code making use of this is only in dpkg
> 1.15 which will only be uploaded in lenny+1.

Lenny is now released. Can we go forward and have this implemented
in base-files ?

You should replace "dpkg (<< 1.15.1)" as we already released dpkg 1.15.0
to experimental and it still contains /etc/dpkg/origins.

Cheers,
-- 
Raphaël Hertzog

Contribuez à Debian et gagnez un cahier de l'admin Debian Lenny :
http://www.ouaza.com/wp/2009/03/02/contribuer-a-debian-gagner-un-livre/


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

Re: Transition from dpkg to GNU install-info

[Guillem Jover]

Hey!

On Mon, 2009-03-16 at 12:34:51 +0100, Raphael Hertzog wrote:
> I can add print this additionnal information in case there's no
> /urs/bin/install-info and we have DPKG_RUNNING_VERSION set.

Checking now the new warning, it might also make sense to print the
package involved from DPKG_MAINTSCRIPT_PACKAGE so the message is more
clear.

> If we have /urs/bin/install-info, it will take care of printing the
> message for us.

Ok.

> We want to avoid to have to coordinate once more for the final move.
> It's best to avoid a system with install-info installed but without
> install-info binary because dpkg was upgraded to a version that doesn't
> provide it.
> 
> IOW, depending on install-info should be enough to ensure that
> install-info exists in $PATH. This can only be true if /usr/bin/install-info 
> is
> part of install-info right from the beginning unless we want to add a
> Breaks: install-info (< first-version-with-usr-bin-install-info) once
> we remove the wrapper from dpkg.
> 
> I prefer to avoid the supplementary Breaks and handle everything now
> without having to remember that we should add the Breaks once we remove
> the wrapper.
> 
> What do you think ?

Given the size of the transition this is going to be a small pain
compared to the total, but yes, you are right, I guess it makes more
sense.

> As long as the one in /usr/sbin/ always ends up calling the one in
> /usr/bin I don't see what the problem is.
> 
> Having two different behaviour depending on the order in PATH would be
> bad, but here we have a single behaviour since the one in /usr/bin gets to
> dictate what's done and the other one is a wrapper. The fact that 
> the install-info package decided to make it a wrapper too (as opposed to
> "patch ginstall-info to have the desired behaviour") should not change
> anything from our point of view.
> 
> A new version of the patch is in my branch, it should fix all the points you
> have brought up (except the common wrapper thing):
> http://git.debian.org/?p=users/hertzog/dpkg.git;a=commitdiff;hb=pu/install-info

I was going to give some comments, but then I thought it was going to
be easier with code, so here it is



this way it might be possible to reuse this as the wrapper for the
install-info package.

regards,
guillem


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