gmane.os.netbsd.devel.packages

Re: Packages with non-distributable distfiles

John Marino — 2012-05-25T15:15:38

I've solved my problem.
I'm probably not going to be around for the next 4 weeks, so I think 
what I've already said stands on it's own merit.



You may believe what you wish - I've been pretty consistent in saying I 
believe the distfile needs to be available to all users or the package 
needs to be removed.  That's got nothing to do with the "free" software 
movement, but everything to do with equal benefits to all users.



No, that's not true.  I added a comment in addition to each tag 
referencing the message that explains it.  Of all the objections, this 
one is really not valid.




Maybe, but one of the drivers is to make it clear to regular users that 
build from source that the package WILL NOT BUILD and THAT'S EXPECTED. 
We've gotten bug reports on these things, and the user was confused why 
the package was broken.  A nice message like "This package is not for 
DragonFly-i386" is clear to them, no confusion.  The bulk build masking 
is nice, but its not the only reason.

John

Re: Packages with non-distributable distfiles

David Holland — 2012-05-25T14:59:10

 > Infrastructure is needed, rules are needed and must be enforced.
 > This sub-project, pkgsrc, has the resources to do that, but isn't.

Formal rules are needed only when there's a social problem that cannot
be solved by community consensus.

Again: what *problem* are you trying to solve?

 > >>I'm sorry, I'm going to continue to believe that packages that
 > >>require distfiles that are illegal to obtain have no place in a
 > >>package system that serves open source operating systems.
 > >
 > >You may believe it, but your beliefs should not impede others.
 > >We're not GNU, and this world still has IP laws. Some software has to be
 > >bought (licensed) in order to be used, and there's significant number of
 > >users who don't see anything wrong with it.
 > 
 > I said nothing about IP laws.  I said "illegal to obtain".  That
 > has been stated as fact several times.  If you have one of these
 > distfiles, you can't legally give it to me.  That's going nothing
 > to do with GNU or IP.

I'm inclined to agree with asau< at >. The criterion you're applying seems
to be based on whether the software is Free.

 > I think you forgot how the whole things started.  I marked these
 > NOT-FOR-DRAGONFLY.  That's it, I was finished.  It was Joerg that
 > put forth a policy proposal (a good one).  I support the proposal,
 > but since I've actually not seen any proposal ever get implemented,
 > I'm skeptical this one will either.  So I spent 3 minutes per
 > package that violates *our* policy without affecting anyone else
 > and I moved on to fixing those important breakages.  So I'm pleased
 > to inform you that the only time I continue to waste on the subject
 > is responding to this thread.

The issue is that by marking the packages that way, rather than with a
semantically-meaningful tag (which would need to be implemented)
you're adding to the entropy of the system. In a few years when this
little argument is long forgotten, it will be (at best) a hassle to
track down why all these packages are marked NOT-FOR-DRAGONFLY.

A semantically-meaningful tag would also allow these packages to stop
polluting the bulk build results on *all* platforms, not just yours,
without making them unavailable.

Re: How to deal with bulk build's "/var/qmail" problem?

David Holland — 2012-05-25T14:46:34

 > Hmmm -
 > My mk.conf defined VARBASE as "/usr/pkg/var" and so did the
 > pbulk.conf file.  But the packages are installing at /var/qmail.
 > 
 > I was going to change the pbulk.conf value to /var in the hopes
 > that would fix it.

I think there's some djb issue with qmail that prevents the package
from honoring $VARBASE correctly.

Re: Brasero 3.0 - ld: cannot find -lltdl

OBATA Akio — 2012-05-25T13:20:37


I don't know about your whole packages and how to rebuild, but something may
still using /usr/X11R7/lib/libXi.so.6.0 instead of /usr/pkg/lib/libXi.so.6.1.0.

How about output of followings?
% pkg_info -Q REQUIRES gtk3+
% ldd /usr/pkg/bin/brasero
% ldd /usr/pkg/lib/libgdk-3.so.0

Re: Brasero 3.0 - ld: cannot find -lltdl

Maurizio Caloro — 2012-05-25T12:49:37

ok now i have rebuild this list but the error exist anyway. 
please exist other way to solv this ?

powermac$ brasero
/usr/pkg/lib//libgdk-3.so.0: Undefined PLT symbol "XIQueryVersion" (symnum =441)

qt3-libs-3.3.8nb18C++ X GUI toolkit
imake-1.0.3nb1Imake and other utilities from modular X.org
libX11-1.3.5Base X libraries from modular Xorg X11
xmlto-0.0.23nb1Tool to help transform XML documents into other formats
xulrunner-12.0XML User Interface Language runtime environment
vim-gtk2-7.2.446nb4Vim editor (vi clone) with X11 GTK2 GUI
libexif-0.6.20nb1EXIF file library
compositeproto-0.4.1Composite extension headers from modular X.org
expat-2.1.0XML parser library written in C
xz-5.0.3XZ utilities
xchat-2.8.8nb3X11 (X Window System) IRC client, using the GTK2 toolkit
gsed-4.2.1nb2GNU implementation of sed, the POSIX stream editor
py26-xml-0.8.4nb3Collection of libraries to process XML with Python
libksba-1.2.0nb1X.509 library
dirmngr-1.1.0nb2X509 certificate and CRL downloader
libXt-1.0.8X Toolkit Intrinsics library
xcb-util-0.3.6XCB Utilities
xcb-2.4nb1Extensible, multiple cut buffers for X
xmlrpc-c-ss-1.16.39Library for writing an XML-RPC server or client in C or C++
libXvMC-1.0.6XVideo Motion Compensation Library
qt4-libs-4.8.0nb4C++ X GUI toolkit
gtk2+-2.24.10nb2GIMP Toolkit v2 - libraries for building X11 user interfaces
xorg-cf-files-1.0.4nb3Xorg imake rules
libXi-1.4.3X Input extension library
kdelibs4-4.8.0nb1Support libraries for the KDE integrated X11 desktop
xf86vidmodeproto-2.3XF86VidMode extension headers from modular X.org
gtk+-1.2.10nb10GIMP Toolkit v1 - libraries for building X11 user interfaces
xmms-1.2.11nb3X Multimedia System - an audio player with a Winamp GUI
libXpm-3.5.8nb1X PixMap Library from modular Xorg X11
xmahjongg-3.70The Chinese game of Mah Jongg for X11
cups-1.5.2nb1Common UNIX Printing System
xterm-259nb2Latest terminal emulator for the X Window System
startup-notification-0.10nb1X11 application startup notification library
gnome-terminal-2.32.1nb5Xterm like terminal program for GNOME 2
xemacs-21.4.22nb7XEmacs text editor version 21
p5-ExtUtils-Depends-0.304Easily build XS extensions that depend on XS extensions
xfconf-4.6.1nb9Xfce client-server configuration storage and query system
libxfce4util-4.6.1nb7Xfce basic library
libxfce4gui-4.6.1nb8Xfce widget library
xfce4-exo-0.3.101nb10Xfce extension library
xfce4-panel-4.6.2nb9Xfce panel
libXext-1.1.1X Extension library
xinput-1.5.2Xinput diagnostic utility for modular X.org
inputproto-2.0Input extension headers from X.org
xproto-7.0.18nb1X protocol and ancillary headers from Xorg X11
xextproto-7.2.0XExt extension headers from X.org
kbproto-1.0.5KB extension headers from X.org
fixesproto-5.0Fixes extension headers from X.org
renderproto-0.11Render extension headers from modular X.org
bigreqsproto-1.1.0BigReqs extension headers from modular Xorg X11
xcmiscproto-1.2.0XCMisc extension headers from X.org
xf86bigfontproto-1.2.0XF86BigFont extension headers from X.org
xtrans-1.2.5Network API translation layer to insulate X
libXau-1.0.6Authorization Protocol for X from X.org
libXdmcp-1.0.3X Display Manager Control Protocol library from X.org
xineramaproto-1.2Xinerama extension headers from X.org
randrproto-1.3.1Randr extension headers from modular X.org
libXrender-0.9.6X Render Library
libXft-2.1.14nb1Library for configuring and customizing font access
libXrandr-1.3.0X RandR Library from X.org
libXfixes-4.0.5Xfixes library and extension of X RandR from modular X.org
libXcomposite-0.4.2X Composite Library
libXcursor-1.1.10Client-side cursor loading library for X
libICE-1.0.6Inter Client Exchange (ICE) library for X
libSM-1.1.1nb1X Session Management Library
libXinerama-1.1X PanoramiX extension library
gtk3+-3.4.3nb1GIMP Toolkit v3 - libraries for building X11 user interfaces

Re: Packages with non-distributable distfiles

Greg Troxel — 2012-05-25T12:35:47

Aleksej Saushev <asau< at >inbox.ru> writes:


In my view, the real issue isn't a purist position about copyright law.
I don't think anyone is objecting to packages that need a distfile that
you have to buy a license to obtain.  We're talking, I think, about
packages with ancient distfiles (that can't legally be copied) and are
no longer obtainable from the original sources.  That just feels like
clutter.

Re: Packages with non-distributable distfiles

John Marino — 2012-05-25T11:55:56

As quickly as possible because I'm sure others are tired of this 
conversation:

- I don't consider commit privilege when talking about users.
- QC comes with a price.  Infrastructure is needed, rules are needed and 
must be enforced.  This sub-project, pkgsrc, has the resources to do 
that, but isn't.  Any criticism about QC by the user is therefore 
justified.  It's really not taxing to identify a bad package and purge 
it, so stating how hard that is isn't going to fly very far.




I said nothing about IP laws.  I said "illegal to obtain".  That has 
been stated as fact several times.  If you have one of these distfiles, 
you can't legally give it to me.  That's going nothing to do with GNU or IP.



Calling me a stallmanist is wrong - I'm not pro-GNU or pro-GPL.  If you 
have an distfile, great, use it.  Use it with a copy of the package 
makefiles made by you before they were purged.  What's so difficult 
about that?





I think you forgot how the whole things started.  I marked these 
NOT-FOR-DRAGONFLY.  That's it, I was finished.  It was Joerg that put 
forth a policy proposal (a good one).  I support the proposal, but since 
I've actually not seen any proposal ever get implemented, I'm skeptical 
this one will either.  So I spent 3 minutes per package that violates 
*our* policy without affecting anyone else and I moved on to fixing 
those important breakages.  So I'm pleased to inform you that the only 
time I continue to waste on the subject is responding to this thread.




I deal with standards in my profession.  Strangely, all of them are 
documented and followed.


While I agree it's polite that new packages build on NetBSD-i386, and 
I've turned down one that didn't build on NetBSD, there are *plenty* of 
packages that were intended only for NetBSD and have no hope of building 
anywhere else, but the same courtesy needs to be extended to other 
platforms.  Agreed, pkgsrc is hosted by NetBSD and a package *should* 
run on NetBSD if it's technically capable but if its not designed to, 
that shouldn't restrict it from getting into pkgsrc.  So if that's a 
firm restriction without exception, it's a bad one.



What do they work on?  Linux?

I don't know, it's a complex subject.  If pkgsrc sells itself as 
universal system, it should have provisions for single platform 
(non-NetBSD) support.  In some cases that single platform could be 
expanded if a developer took interest.

John

Re: Packages with non-distributable distfiles

Joerg Sonnenberger — 2012-05-25T11:53:29

*sigh* Can we please go back to the original proposal? It was very
explicit about NOT covering commercial software as long as there is a
maintainer to ensure that the software can be bought.

I don't commit a package for my own commercial software, because it
would be useless for anyone except maybe my own customers. I consider
vanishingware with restricted licenses pretty much the same. I gave one
good example outside the scope of this proposal to abs< at > already with
Java. I'm perfectly fine with the SAP packages. I am maintainer of the
Python Oracle binding, which is useless without having access to an
Oracle installation. All this cases are fine. I'd call net/skype
border line and lots of other things beyond the border. So far I have
seen no real reason why the rule I gave doesn't cover the relevant
cases.

Joerg

Re: Packages with non-distributable distfiles

Aleksej Saushev — 2012-05-25T11:29:24


Yes, some users are more equal than others one way or another,
not everyone can commit his local changes to the repository.
If you think that quality control comes with no price, you're mistaken,
it takes a good deal of resources.


You may believe it, but your beliefs should not impede others.
We're not GNU, and this world still has IP laws. Some software has to be
bought (licensed) in order to be used, and there's significant number of
users who don't see anything wrong with it.

Some countries are even that strict that deny what is considered "fair use,"
and thus you have to break the law if you want to use some software.


I don't see the reason why users should suffer from purist views of one
or few developers.

What you're striving for is completely different from recent move
towards staged installation as requirement. The latter has clear
technical advantages, but some packages have to be purged out for it.
In constrast, your goal is limited to exclusion of packages
with no other benefit than some kind of stallmanist "freedom."


There're a lot of other things to work on than chasing packages that
don't work for you personally and shooting them down. Especially,
when they don't affect anything else.


Yes, there're a lot of standards. If you expect that everything should
be fixed and written down, you should look for another world, because
this one works differently to such expectations.

In particular, it is expected that new package builds on NetBSD/i386 at
least, and it is required that a package is distributed in files.
This alone places a lot of restrictions. If these were relaxed, I could
have imported some packages that don't work on NetBSD since 1.1-1.4 days,
and a number of packages that fetch source from VCS directly. Personally,
I don't have major problems with using VCS as distribution method, but
some "paranoids" (security infected people) do. So do some other people.

Re: How to deal with bulk build's "/var/qmail" problem?

Hans Rosenfeld — 2012-05-25T10:36:53

And they should be fixed. All of them. :)

I only noticed it with qmail because it showed up in the "causing most
breakage" list in my builds.


That would be very interesting, although the packages should still be
fixed.


Hans

Re: How to deal with bulk build's "/var/qmail" problem?

John Marino — 2012-05-25T10:11:44


Yeah, I was surprised that it wasn't using $VARBASE, but it's a lot of 
mail packages, not just one.  And other packages install directly to 
/var as well.  Probably wrong, but they do.

I'm building with pbulk.conf VARBASE set to /var, so I'll let you know 
if that makes things better or worse.

John

Re: How to deal with bulk build's "/var/qmail" problem?

Hans Rosenfeld — 2012-05-25T10:03:17

I noticed problems with /var/qmail. I even looked at it for a brief
moment, but then I decided there are more important things to fix (for
SunOS, at least).

I don't know if it is related to the build problems, but the package
shouldn't touch /var at all, it should use ${VARBASE}.


Hans

Re: How to deal with bulk build's "/var/qmail" problem?

John Marino — 2012-05-25T09:49:02

Hmmm -
My mk.conf defined VARBASE as "/usr/pkg/var" and so did the pbulk.conf 
file.  But the packages are installing at /var/qmail.

I was going to change the pbulk.conf value to /var in the hopes that 
would fix it.

John

Re: How to deal with bulk build's "/var/qmail" problem?

Benny Siegert — 2012-05-25T09:34:59


Ah, sorry. I am building with VARBASE=/usr/pkg/var so the directory is pruned.

--Benny.

Re: Packages with non-distributable distfiles

John Marino — 2012-05-25T08:43:25

So it broadcasts to the users that pkgsrc quality control sucks, and 
also invokes Animal Farm ideas where some users are more equal than others.




I'm sorry, I'm going to continue to believe that packages that require 
distfiles that are illegal to obtain have no place in a package system 
that serves open source operating systems.




Yes, my "unusual tastes" of expecting something to work as advertised. 
I don't like the fact that there are really no standards at all for what 
packages have membership, or the fact that a single person can say "I 
want to keep that package" when 99 people want to get rid it. 
Establish some clear standards and prune packages when they violate 
those standards and stop taking a poll to find a single person that 
wants to keep the garbage to justify keeping it.




Right, because based on my commits over the last 6 months, that's all 
I've been concentrating on.




LOL.  "if only standards were a bit relaxed?"
How can they get lower?  Maybe it's hard to get packages in, but it's 
impossible to get them out.  There's not even a formal way of doing it

Re: Packages with non-distributable distfiles

Aleksej Saushev — 2012-05-25T08:29:41


Yes, so what?

At least each fifth package doesn't build for everybody.
Even less packages work. That's not the reason to remove them.


No, it isn't. It does build package. Get the distfile and might build it.


In this particular case you're fighting to remove packages that might be
still useful for some people in order to appease your unusual tastes.
Removal of packages doesn't fix anything except creating obstacles to
people who are or might be using them. Removal of leaf packages doesn't
have any impact besides numbers in bulk build report. And these numbers
are the only thing that constitutes the "problem" you're trying to "solve."

Seriously, you should really find better place to waste your efforts than
reducing number of broken packages from around 470 to around 470 with no
other effect visible or invisible.


Yes, WIP would suffer.

It carries enough stable packages that would be in pkgsrc already, and
enough software that could be, if only standards were a bit relaxed.
But instead of pushing stable software from WIP to pkgsrc, just like it
was meant originally, the opposite is proposed.

Re: How to deal with bulk build's "/var/qmail" problem?

John Marino — 2012-05-25T08:23:38

I'm looking at the script libexec/client-clean, and right before the 
tarball extraction is the line:
rm  -rf ${cur_destdir}${varbase}/qmail 2> /dev/null || true.

So it's trying to clear that, but one of the variables must have the 
wrong value.

John

Re: How to deal with bulk build's "/var/qmail" problem?

John Marino — 2012-05-25T08:14:07

Okay, I checked the bootstrap.  It's only dealing with /usr/pkg as you 
said.  The problem is with /var/qmail, not /usr/pkg/var/qmail, so the 
bootstrap isn't coming into play here.

John

Re: How to deal with bulk build's "/var/qmail" problem?

John Marino — 2012-05-25T08:09:42

Hi Benny,
So you are saying my bootstrap tarball is corrupt?

I'm using pbulk.
I'll unpack it and see what's there - clear out the garbage.

Thanks,
John

Re: How to deal with bulk build's "/var/qmail" problem?

Benny Siegert — 2012-05-25T07:57:58

The way pbulk does it is by clearing /usr/pkg and unpacking a
bootstrap tarball before _each_ package is built.

--Benny.

How to deal with bulk build's "/var/qmail" problem?

John Marino — 2012-05-25T06:14:44

I don't know if this is a misconfiguration on my part or what, but while 
looking over bulkbuild results, I've noticed that over a dozen mail 
packages are failing in the configure stage.

They are complaining that "/var/qmail" already exists and that it needs 
to be deleted before continuing.  One package is creating that directory 
and it never gets removed afterward, so the following packages that are 
sensitive to it fail.

I assume I'm not the first person to have noticed this.  How do you deal 
with it to get those following packages building too?

John