headers
Thomas Klausner | 1 Apr 2012 13:24
Picon

[HEADS UP] packages not supporting destdir

Last call:

ArX-2.2.4nb19
aqsis-0.6.4nb9
arla-0.43nb2
courier-authlib-0.63.0
cross-i386-cygwin32-1.0.0.0nb3
cross-i386-linux-2.0.7.1nb2
cross-i386-msdosdjgpp-2.02.0nb2
cvsup-16.1.hnb2
cvsup-gui-16.1.hnb3
darcs-2.0.2nb4
ezm3-1.2nb2
gcc3-ada-3.3.6
gcc34-ada-3.4.6nb1
gdbada-6.3nb3
ghc-6.8.3nb2
hanzim-1.3nb1
ispman-0.5nb5
jessie-1.0.1
nhc98-1.18nb2
nn-6.7.3
objc-3.2.6
ocsigen-0.6.0nb4
octave-forge-2006.03.17nb7
pnetC-0.6.6nb2
ruby193-thrift-0.7.0nb1
ruby193-thrift_client-0.7.1
sope-4.5.4nb9
sysinfo-3.5.1
(Continue reading)

Permalink | Reply | 34 comments |
headers
Aleksej Saushev | 1 Apr 2012 15:01
Picon

Re: [HEADS UP] packages not supporting destdir

Thomas Klausner <wiz <at> NetBSD.org> writes:

> Last call:

I strongly object such "last calls" that affect packages in use like:

> courier-authlib-0.63.0

Used in any Courier installation.

> darcs-2.0.2nb4
> ghc-6.8.3nb2

Used by any Haskell user, darcs being used even outside Haskell community.

> nhc98-1.18nb2

Still may be used by some Haskell users.

> ocsigen-0.6.0nb4
> wxhaskell-0.9.4nb19

Still may be used by some O'Caml (e.g. my colleague) and Haskell users.

> I plan to remove these packages after the freeze if noone converts
> them. There was plenty of time.

No, there wasn't, and there's still no need to remove them until it is
proved that these packages don't build and don't install for a long time.
(Continue reading)

Permalink | Reply | 8 comments |
headers
Thomas Klausner | 1 Apr 2012 15:20
Picon

Re: [HEADS UP] packages not supporting destdir

On Sun, Apr 01, 2012 at 05:01:52PM +0400, Aleksej Saushev wrote:
> > I plan to remove these packages after the freeze if noone converts
> > them. There was plenty of time.
> 
> No, there wasn't, and there's still no need to remove them until it is
> proved that these packages don't build and don't install for a long time.

I've been asking for these and other packages to be fixed in particular for over 10 months now.
http://mail-index.netbsd.org/pkgsrc-users/2011/05/18/msg014430.html]

What is enough time?
 Thomas
Permalink | Reply | 4 comments |
headers
Robert Elz | 1 Apr 2012 15:38
Picon

Re: [HEADS UP] packages not supporting destdir

    Date:        Sun, 1 Apr 2012 13:24:32 +0200
    From:        Thomas Klausner <wiz <at> NetBSD.org>
    Message-ID:  <20120401112432.GB16022 <at> danbala.tuwien.ac.at>

These two

  | cvsup-16.1.hnb2
  | cvsup-gui-16.1.hnb3

require this one

  | ezm3-1.2nb2

(which itself is useful for nothing other than building cvsup as I
understand it), and so there's no point working on them if ezm3 isn't
fixed first (if ezm3 were removed, cvsup would be unbuildable anyway.)

The ezm3 Makefile (do-build target) says ...

  <at> ${ECHO} "===================================================================";
  <at> ${ECHO} "As per the website, it is NOT possible to separate the build process"
  <at> ${ECHO} "from the installation process."
  <at> ${ECHO} "'${MAKE} install' will build AND install the package."
  <at> ${ECHO} "===================================================================";

(to be honest, I deleted a few ='s in the first and last of those lines
to keep the line lengths of this e-mail shorter).

The website mentioned says ...
(Continue reading)

Permalink | Reply | 12 comments |
headers
Takahiro Kambe | 1 Apr 2012 16:03
Gravatar

Re: [HEADS UP] packages not supporting destdir

In message <20120401112432.GB16022 <at> danbala.tuwien.ac.at>
	on Sun, 1 Apr 2012 13:24:32 +0200,
	Thomas Klausner <wiz <at> NetBSD.org> wrote:
> ruby193-thrift-0.7.0nb1
> ruby193-thrift_client-0.7.1
They are depends on libthrift.
I could build them 6th Mar. 2012 and now updating my work area...

--

-- 
Takahiro Kambe <taca <at> back-street.net>
Permalink | Reply | 6 comments |
headers
Thomas Klausner | 1 Apr 2012 16:35
Picon

Re: [HEADS UP] packages not supporting destdir

[ezm3]
On Sun, Apr 01, 2012 at 08:38:17PM +0700, Robert Elz wrote:
> In any case, all of this looks as if it is simply incompatible with
> destdir builds, and so incompatible that the people who distribute the
> software just tell you not to bother trying.

Hm. Good point, that's annoying. Perhaps removing the packages isn't
the solution then, so I'll step down from that proposal.

I'd still suggest that interested people would convert the ones that
are less impossible to change to destdir.
 Thomas
Permalink | Reply | 0 comments |
headers
Aleksej Saushev | 1 Apr 2012 17:13
Picon

Re: [HEADS UP] packages not supporting destdir

Thomas Klausner <wiz <at> NetBSD.org> writes:

> On Sun, Apr 01, 2012 at 05:01:52PM +0400, Aleksej Saushev wrote:
>> > I plan to remove these packages after the freeze if noone converts
>> > them. There was plenty of time.
>> 
>> No, there wasn't, and there's still no need to remove them until it is
>> proved that these packages don't build and don't install for a long time.
>
> I've been asking for these and other packages to be fixed in particular for over 10 months now.
> http://mail-index.netbsd.org/pkgsrc-users/2011/05/18/msg014430.html]
>
> What is enough time?

Until it either gets fixed or dies out naturally.

This issue is serious. We do harm to NetBSD and pkgsrc acceptance by removing
packages on arbitrary grounds. You should present strong reasons why the lack
of staged installation support should be the reason to remove fully functional
packages. Note that it is fundamentally different from removal of old bulk
build code or, perhaps, alternatives framework. We have pkg_comp and other
facilities to isolate package builds, if potential side effects do really matter.
There's absolutely no reason to remove packages that don't support staged
installation, especially when it is done just for mere convenience of few developers.

There're other issues, communicational and organizational. I think that
forcing some developers to work on packages just to appease some
strange tastes of others is plain wrong. If you have time and consider
it really important, why don't you do it yourself? O'Caml and Haskell
are still popular programming languages, and you cannot change that,
(Continue reading)

Permalink | Reply | 3 comments |
headers
Aleksej Saushev | 1 Apr 2012 17:25
Picon

Re: [HEADS UP] packages not supporting destdir

Robert Elz <kre <at> munnari.OZ.AU> writes:

> These two
>
>   | cvsup-16.1.hnb2
>   | cvsup-gui-16.1.hnb3
>
> require this one
>
>   | ezm3-1.2nb2
>
> (which itself is useful for nothing other than building cvsup as I
> understand it), and so there's no point working on them if ezm3 isn't
> fixed first (if ezm3 were removed, cvsup would be unbuildable anyway.)

...

> In any case, all of this looks as if it is simply incompatible with
> destdir builds, and so incompatible that the people who distribute the
> software just tell you not to bother trying.
>
> I really don't want to see these go, I use cvsup (the gui not often, so
> that small part of it is less important) and for that, I need ezm3 (or
> perhaps some other modula3 compiler) to build it (for now, exm3 is the only
> one I know of in pkgsrc).
>
> What's more, I don't use destdir builds, and have no plans on ever doing so.
> I build in a pkg_comp sandbox, which has more or less the same results
> (binary packages get built without affecting the real system, then the
> binary package can be installed).   That's pretty much what destdir is
(Continue reading)

Permalink | Reply | 0 comments |
headers
Takahiro Kambe | 1 Apr 2012 18:14
Gravatar

Re: [HEADS UP] packages not supporting destdir

In message <20120401.230325.1898388364693445033.taca <at> back-street.net>
	on Sun, 01 Apr 2012 23:03:25 +0900 (JST),
	Takahiro Kambe <taca <at> back-street.net> wrote:
> In message <20120401112432.GB16022 <at> danbala.tuwien.ac.at>
> 	on Sun, 1 Apr 2012 13:24:32 +0200,
> 	Thomas Klausner <wiz <at> NetBSD.org> wrote:
>> ruby193-thrift-0.7.0nb1
>> ruby193-thrift_client-0.7.1
> They are depends on libthrift.
> I could build them 6th Mar. 2012 and now updating my work area...
And devel/libthrift fails for me (on NetBSD/amd64 6.0_BETA).

=> Generating post-install file lists
pkg_create: can't stat `/pkg_comp/obj/pkgsrc/devel/libthrift/default/.destdir/usr/pkg/share/doc/thrift/java/resources/inherit.gif'
=> Checking file-check results for libthrift-0.7.0nb5
ERROR: ************************************************************
ERROR: The following files are in the PLIST but not in /usr/pkg:
ERROR:         /pkg_comp/obj/pkgsrc/devel/libthrift/default/.destdir/usr/pkg/share/doc/thrift/java/resources/inherit.gif
ERROR: ************************************************************
ERROR: The following files are in /usr/pkg but not in the PLIST:
ERROR:         /pkg_comp/obj/pkgsrc/devel/libthrift/default/.destdir/usr/pkg/share/doc/thrift/java/resources/background.gif
ERROR:         /pkg_comp/obj/pkgsrc/devel/libthrift/default/.destdir/usr/pkg/share/doc/thrift/java/resources/tab.gif
ERROR:         /pkg_comp/obj/pkgsrc/devel/libthrift/default/.destdir/usr/pkg/share/doc/thrift/java/resources/titlebar.gif
ERROR:         /pkg_comp/obj/pkgsrc/devel/libthrift/default/.destdir/usr/pkg/share/doc/thrift/java/resources/titlebar_end.gif
*** Error code 1

Best regards.

--

-- 
Takahiro Kambe <taca <at> back-street.net>
(Continue reading)

Permalink | Reply | 5 comments |
headers
Mayuresh | 1 Apr 2012 19:13
Picon
Favicon

wip/muttprint functionality issue

muttprint is a wip package I created a few days back.

Came across what seems a really serious bug in its functionality to me.

It will be too long to describe it fully. Just giving short gist here: If
an email thread does not follow the ">" convention uniformly (i.e. some
replies start lines with ">" and some don't) in the printed version that
muttprint creates, the contents of mails get intermixed.

I have communicated this to upstream. Last time I interacted regarding
some patches, got to know the next release might be in May or so. Hoping
that this issue, too, will get fixed.

I will update wip package after that.

I could get away with my printing job using mp, when faced with above
problem. mp works fine for me though muttprinit provides more
configurability.

Mayuresh.
Permalink | Reply | 0 comments |

Gmane