On 2008-06-10, Martin Etteldorf <etteldor@email.lu> wrote:[color=blue][color=green][color=darkred]
>>> This is the case every time gettext updates. It's nothing new. The
>>> problem is so many things pulling in gettext. An even more real
>>> problem is things pulling in gettext surreptitiously just because
>>> it's on the system. I ranted about this on my blog:[/color]
>>
>> Yes, I remember funny upgrade of libtool or perl too.[/color]
>
> You're sure about the libtool part?[/color]

Yes. Note that the big catch was not libtool, but changed naming of ports.
E.g. gtk12 changed into gtk-1.2

06-11-2008, 09:02 AM

unix

Re: gettext/GPLv4 virus infects FreeBSD

Robert Melson <melsonr@aragorn.rgmhome.net> wrote:
[color=blue]
> Days. Yeah, I know, it's a function of what you have installed.
> I have chosen to use my system as a workstation,[/color]

I'm doing that as well, and -- believe it or not -- you can still
live fine without Gnome and KDE.
[color=blue]
> However, without adding any new applications, my "inventory"
> has gone from ~500 discrete ports/packages to > 1000 in less
> than a year. Part of that is the new granularity in, e.g.
> php and its modules, but a large part of it is what seems to me
> to be a kind of shotgun approach to packaging, where something
> that's not explicitly needed is included "just in case".[/color]

Maybe some cleanup will help. e.g. I don't need no 3 versions of
libtool, automake/-conf/-whatever, neither do I need different
versions of gcc.
Sometimes it helps checking if you have installed ports with no
dependencies in either direction as well. Usually you can just
safely drop them.

Martin

--
"For the Snark's a peculiar creature, that won't
Be caught in a commonplace way.
Do all that you know, and try all that you don't;
Not a chance must be wasted to-day!"

Neither do I, but as I need some fortran, I get them for love on FreeBSD.
--
Dipl.-Math. Wilhelm Bernhard Kloke
Institut fuer Arbeitsphysiologie an der Universitaet Dortmund
Ardeystrasse 67, D-44139 Dortmund, Tel. 0231-1084-373
PGP: [url]http://vestein.arb-phys.uni-dortmund.de/~wb/mypublic.key[/url]

06-11-2008, 10:32 AM

unix

Re: gettext/GPLv4 virus infects FreeBSD

Martin Etteldorf <etteldor@email.lu> writes:
[color=blue]
>Robert Melson <melsonr@aragorn.rgmhome.net> wrote:[/color]
[color=blue][color=green]
>> Days. Yeah, I know, it's a function of what you have installed.
>> I have chosen to use my system as a workstation,[/color][/color]
[color=blue]
>I'm doing that as well, and -- believe it or not -- you can still
>live fine without Gnome and KDE.[/color]

Just before I was about to say `yes' I double-checked, and I seem to
have it installed on my system. Probably because I needed it for dvds,
but this box doesn't have a dvd burner installed, only a cd burner. For
that, burncd (from base) does just fine.

Can you live with a cdrecord without rscsi and cddb? I can, and mine has
exactly no dependencies according to pkg_info. It's probably why I added
atapicam to the kernel, though.

--
j p d (at) d s b (dot) t u d e l f t (dot) n l .
This message was originally posted on Usenet in plain text.
Any other representation, additions, or changes do not have my
consent and may be a violation of international copyright law.

06-11-2008, 02:03 PM

unix

Re: gettext/GPLv4 virus infects FreeBSD

Thierry Thomas <tthomas@mail.dotcom.fr> wrote:[color=blue]
> On Tue, 10 Jun 2008 18:18:55 -0500, Robert Melson wrote:
>[color=green]
> > So, yeah, days. Not hours, but days to upgrade the ports on my
> > system.[/color]
>
> In these cases, just wait some days, and then use the packages built on
> the compilation farm; just upgrade from ports when you have some
> customized options.[/color]

An option which is considered as the devil's tentation by many FreeBSD
users, (note i have not said the penguin's way) and lacks proper tools
to be used comfortably ...

--

Michel TALON

06-11-2008, 02:12 PM

unix

Re: gettext/GPLv4 virus infects FreeBSD

Marco van de Voort <marcov@stack.nl> wrote:[color=blue]
> On 2008-06-10, Martin Etteldorf <etteldor@email.lu> wrote:[color=green][color=darkred]
> >>> This is the case every time gettext updates. It's nothing new. The
> >>> problem is so many things pulling in gettext. An even more real
> >>> problem is things pulling in gettext surreptitiously just because
> >>> it's on the system. I ranted about this on my blog:
> >>
> >> Yes, I remember funny upgrade of libtool or perl too.[/color]
> >
> > You're sure about the libtool part?[/color]
>
> Yes. Note that the big catch was not libtool, but changed naming of ports.
> E.g. gtk12 changed into gtk-1.2[/color]

When i wrote my paper on the FreeBSD ports system, the constant mania of
changing the names of ports seemd to me to be the biggest gripe against
the system. At least this is the sort of thing which brings absolutely
nothing positive (except comforting the ego of some bikeshed painters)
and causes a lot of trouble for ports management.

--

Michel TALON

06-11-2008, 04:25 PM

unix

Re: gettext/GPLv4 virus infects FreeBSD

In article <dRN3k.400$NV4.349@newsfe02.lga>,
J. Porter Clark <jpc@porterclark.com> wrote:[color=blue]
>Martin Etteldorf <etteldor@email.lu> writes:
>[color=green]
>>Robert Melson <melsonr@aragorn.rgmhome.net> wrote:[/color]
>[color=green][color=darkred]
>>> Days. Yeah, I know, it's a function of what you have installed.
>>> I have chosen to use my system as a workstation,[/color][/color]
>[color=green]
>>I'm doing that as well, and -- believe it or not -- you can still
>>live fine without Gnome and KDE.[/color]
>
>Yes, but can you live without cdrecord? 8-([/color]

Well, you are right never versions of cdrtools include libfind which
is by default compiled against gettext(3). I thought that GNU gettext(3)
if LGPL and did not care. I just checked gettext-0.17 which seems
to bee the latest and gettext(3) is still LGPLv2.

As cdrtools are now nearly completely under CDDL, a change from LGPL
to GPL for one of the external libraries would be a major problem.

J. Porter Clark <jpc@porterclark.com> wrote:[color=blue]
> Martin Etteldorf <etteldor@email.lu> writes:
>[color=green]
>>Robert Melson <melsonr@aragorn.rgmhome.net> wrote:[/color]
>[color=green][color=darkred]
>>> Days. Yeah, I know, it's a function of what you have installed.
>>> I have chosen to use my system as a workstation,[/color][/color]
>[color=green]
>>I'm doing that as well, and -- believe it or not -- you can still
>>live fine without Gnome and KDE.[/color]
>
> Yes, but can you live without cdrecord? 8-([/color]

Yes. *For me*, burncd and dvd+rw-tools are sufficient.

BTW: cdrecord needs neither gettext nor iconv if you have set
WITHOUT_NLS=yes in your build environment. Setting this is a good
idea anyway if you don't need it, as it also helps a lot to avoid
installing unnecessary packages.

Martin

--
"For the Snark's a peculiar creature, that won't
Be caught in a commonplace way.
Do all that you know, and try all that you don't;
Not a chance must be wasted to-day!"

06-12-2008, 02:27 AM

unix

Re: gettext/GPLv4 virus infects FreeBSD

Joerg Schilling <js@cs.tu-berlin.de> wrote:[color=blue]
>Well, you are right never versions of cdrtools include libfind which
>is by default compiled against gettext(3). I thought that GNU gettext(3)
>if LGPL and did not care. I just checked gettext-0.17 which seems
>to bee the latest and gettext(3) is still LGPLv2.[/color]

Interesting. When I:

cd /usr/ports/devel/gettext
make
more work/gettext-0.17/NEWS

it clearly indicates:

* License:
The gettext related programs and tools are now licensed under the GPL
version 3, instead of the GPL version 2. The libintl library continues
to be licensed under LGPL.

So does this mean that any commercial, non-OSS application developer
who calls crdrtools from their app can now be sued, regardless of whether
they modify your code or not?

Paco

06-12-2008, 02:33 AM

unix

Re: gettext/GPLv4 virus infects FreeBSD

Anton Hartl <anton.hartl@gmail.com> wrote:[color=blue]
>Furthermore it's simply a half-truth; from the ChangeLog:
>
> The gettext related programs and tools are now licensed under the GPL
> version 3, instead of the GPL version 2. The libintl library continues
> to be licensed under LGPL.[/color]

How does libintl relate? If I use an app that links to gettext will it
call libintl instead, if gettext isn't installed?

Paco

06-12-2008, 02:36 AM

unix

Re: gettext/GPLv4 virus infects FreeBSD

Robert Melson <melsonr@aragorn.rgmhome.net> wrote:[color=blue]
>So, yeah, days. Not hours, but days to upgrade the ports on my
>system.[/color]

None of which does anything other than resynchronize your port version
numbers (assuming you didn't upgrade gettext in the first place).
That's negative ROI to the accountants and other suits, budget
down the drain for those of us paying the sysadmins, and a waste of
time to those doing the upgrades.

Not a good way to do release management, whether or not it is in
the base OS.

Paco

06-12-2008, 02:54 AM

unix

Re: gettext/GPLv4 virus infects FreeBSD

jpd <read_the_sig@do.not.spam.it.invalid> wrote:[color=blue]
>As do I to an extent, but as others have noted, the problem is pretty
>much independent from the base system. That distinction is important.[/color]

Except that they're both essential components of FreeBSD and both play
a key role in differentiating FreeBSD from other Unix/Linux OS'.

Taking the laissez-faire approach to release management, as per Philip's
opinion that ports "merely tracks the upstream version", diminishes
FreeBSD's value against the competition. You can bet Ubuntu doesn't let
application version numbers skew like this. Note which of these two OS
(Ubuntu and FreeBSD) is gaining market share and which is losing it...
[color=blue]
>Though one could argue that the ports maintainers could be a bit more
>careful about updates of things that touch a lot of other things, and
>especially their timing. I think I'll agree with that.[/color]

A bit more careful, well yes, to put it mildly. For my own part I'd
prefer a forked gettext, at GPLv2, giving individual port maintainers
the decision of which to use. That sure beats forcing version upgrades
on sysadmins and port maintainers from on high.
[color=blue]
>Management will just have to cope. If they don't understand that,
>they're not fit for management.[/color]

It's not just management... There's a lot of pressure on organizations to
move from FreeBSD to Linux. Just look at Yahoo, once a solid FreeBSD
shop, which recently mandated RHEL for all new projects. Do you think
they don't understand the relative costs and benefits?
[color=blue]
>I think that I somewhat sympathise, if not with the OP's tone, but with
>the sentiment that the FreeBSD project overall, base and ports both,
>has coasted somewhat into a ``well it works for me'' mindset, which is
>rather unhelpful if your setup is valid but somewhat different.[/color]

Sure looks that way from here. Is this (applying some best practices
to ports tree management) anything the FeeBSD foundation would look at?

Paco

06-12-2008, 07:15 AM

unix

Re: gettext/GPLv4 virus infects FreeBSD

Begin <48508fd0$0$17175$742ec2ed@news.sonic.net>
On 12 Jun 2008 02:54:08 GMT, Paco <nospamforme@sonic.net> wrote:[color=blue]
> jpd <read_the_sig@do.not.spam.it.invalid> wrote:[color=green]
>>As do I to an extent, but as others have noted, the problem is pretty
>>much independent from the base system. That distinction is important.[/color]
>
> Except that they're both essential components of FreeBSD and both play
> a key role in differentiating FreeBSD from other Unix/Linux OS'.[/color]

True enough. But you still have to be careful making blanket statements
about either, or attribute things to it that neither does or is.

The ports system strictly seen only tracks the patches needed to make the
upstream releases build and work on FreeBSD. The goal is just that, that
and giving you a tool to build softare and optionally put it in packages.
It does make fixing broken applications then submitting patches back to
the maintainer(s) easier over a binary emphasised system.

Ubuntu does something different entirely. It provides a full set of
supported software in binaries. Worse, it seems to just fail to tell
the upstream of the patches it created to fix bugs and other things.

FreeBSD's ``supported'' stuff is in the base system, the rest just
happens to work.

[color=blue]
> Note which of these two OS (Ubuntu and FreeBSD) is gaining market
> share and which is losing it...[/color]

Cheap shot, and few here will care. Simply because ubuntu does something
different for a different market, starting from a different premise and
using a different system. If that's where you feel more comfy, or what
your skillset is more suited for, well, go ahead and switch.

Ubuntu is probably more comparable with PC-BSD in terms of its goals.

[color=blue]
> For my own part I'd prefer a forked gettext, at GPLv2, giving
> individual port maintainers the decision of which to use.[/color]

That would put a lot more strain on keeping the ports tree stable
and compiling than a simple licence change that doesn't affect the
substantial part of the package (the library).

You can argue about the wisdom of tracking the change right away, but
forking I don't feel is an adequate solution. There are other ways to
soften the impact of the change, though. You can keep the change out of
your local ports tree until you're ready to do a full rebuild.

[color=blue][color=green]
>>Management will just have to cope. If they don't understand that,
>>they're not fit for management.[/color]
>
> It's not just management... There's a lot of pressure on organizations to
> move from FreeBSD to Linux. Just look at Yahoo, once a solid FreeBSD
> shop, which recently mandated RHEL for all new projects. Do you think
> they don't understand the relative costs and benefits?[/color]

From past discussions with people who then were working or used to work
at yahoo, they've been moving that way for a long time now, from what
I gather due to management sillyness, certain divisions losing clue,
perhaps inter-division infighting, and other bigcorp mis-situations.

Had they moved to, oh, gentoo, then I would've been lots more worried
about FreeBSD and its ports system.

One could debate setting up an enterprise FreeBSD distributor and
support operation, but I don't have enough of an idea to guestimate
whether there's enough market to sustain such a thing.

It'd be an interesting venture, though.

[color=blue]
> Is this (applying some best practices to ports tree management)
> anything the FeeBSD foundation would look at?[/color]

I don't know. Ask them?

I think it is probably worth a shot.

--
j p d (at) d s b (dot) t u d e l f t (dot) n l .
This message was originally posted on Usenet in plain text.
Any other representation, additions, or changes do not have my
consent and may be a violation of international copyright law.

06-12-2008, 08:34 AM

unix

Re: gettext/GPLv4 virus infects FreeBSD

In article <slrng4vgnp.2ra2.read_the_sig@mantell0.local>,
jpd <read_the_sig@do.not.spam.it.invalid> wrote:
[color=blue]
>Can you live with a cdrecord without rscsi and cddb? I can, and mine has
>exactly no dependencies according to pkg_info. It's probably why I added
>atapicam to the kernel, though.[/color]

I am not sure what you refer to, but it may be that you use a very old version
of cdrecord/cdrtools.

Since a year, at least mkisofs depends on gettext(3) and iconv(3).

If you did not install the related software, it still compiles but you
will not be able to correctly work in a UTF-8 based user environment.

In article <g2p9lb$h5j$1@kadath.gruftie.net>,
Martin Etteldorf <etteldor@email.lu> wrote:[color=blue]
>J. Porter Clark <jpc@porterclark.com> wrote:[color=green]
>> Martin Etteldorf <etteldor@email.lu> writes:
>>[color=darkred]
>>>Robert Melson <melsonr@aragorn.rgmhome.net> wrote:[/color]
>>[color=darkred]
>>>> Days. Yeah, I know, it's a function of what you have installed.
>>>> I have chosen to use my system as a workstation,[/color]
>>[color=darkred]
>>>I'm doing that as well, and -- believe it or not -- you can still
>>>live fine without Gnome and KDE.[/color]
>>
>> Yes, but can you live without cdrecord? 8-([/color]
>
>Yes. *For me*, burncd and dvd+rw-tools are sufficient.[/color]

Looks like a funny missunderstanding.....

burncd is non-portable and both programs do not implement the
features you get from cdrecord. In addition both programs still
require mkisofs which is maintained as part of cdrtools since
more than 10 years now.

[color=blue]
>BTW: cdrecord needs neither gettext nor iconv if you have set
>WITHOUT_NLS=yes in your build environment. Setting this is a good
>idea anyway if you don't need it, as it also helps a lot to avoid
>installing unnecessary packages.[/color]

The build system does not understand something like "WITHOUT_NLS=yes"
and mkisofs will not be able to work correctly in a UTF-8 based locale
if there is no iconv(3).

In article <48508991$0$17175$742ec2ed@news.sonic.net>,
Paco <spamfree@sonic.net> wrote:[color=blue]
>Joerg Schilling <js@cs.tu-berlin.de> wrote:[color=green]
>>Well, you are right never versions of cdrtools include libfind which
>>is by default compiled against gettext(3). I thought that GNU gettext(3)
>>if LGPL and did not care. I just checked gettext-0.17 which seems
>>to bee the latest and gettext(3) is still LGPLv2.[/color]
>
>Interesting. When I:
>
> cd /usr/ports/devel/gettext
> make
> more work/gettext-0.17/NEWS
>
>it clearly indicates:
>
> * License:
> The gettext related programs and tools are now licensed under the GPL
> version 3, instead of the GPL version 2. The libintl library continues
> to be licensed under LGPL.[/color]

As I mentioned already: gettext(3) is still under LGPLv2
[color=blue]
>So does this mean that any commercial, non-OSS application developer
>who calls crdrtools from their app can now be sued, regardless of whether
>they modify your code or not?[/color]

See above: cdrtools use gettext(3) and iconv(3). These functions are
inside LGPLv2 libs.

If these functions are ever converted into GPL, then distributors (not
authors likee me or users) may be sued. This e.g. is why you need to take
care to avoid "libcdio" for GNOME on FreeBSD.

Begin <6bc5c8F3536jaU1@mid.dfncis.de>
On 12 Jun 2008 08:34:16 GMT, Joerg Schilling <js@cs.tu-berlin.de> wrote:[color=blue]
> I am not sure what you refer to, but it may be that you use a very old
> version of cdrecord/cdrtools.[/color]

Quite possible. This is *checks* cdrtools-2.01_6.

[color=blue]
> If you did not install the related software, it still compiles but you
> will not be able to correctly work in a UTF-8 based user environment.[/color]

Mine isn't UTF-8 so I wouldn't've noticed.

Gettext and iconv are installed, but pkg_info -xrR cdrtools doesn't show
any dependencies. Might also be a broken package database, of course.
I'll have to check that soonish.

--
j p d (at) d s b (dot) t u d e l f t (dot) n l .
This message was originally posted on Usenet in plain text.
Any other representation, additions, or changes do not have my
consent and may be a violation of international copyright law.

06-12-2008, 10:47 AM

unix

Re: gettext/GPLv4 virus infects FreeBSD

In article <slrng51pp4.2ur9.read_the_sig@mantell0.local>,
jpd <read_the_sig@do.not.spam.it.invalid> wrote:[color=blue]
>Begin <6bc5c8F3536jaU1@mid.dfncis.de>
>On 12 Jun 2008 08:34:16 GMT, Joerg Schilling <js@cs.tu-berlin.de> wrote:[color=green]
>> I am not sure what you refer to, but it may be that you use a very old
>> version of cdrecord/cdrtools.[/color]
>
>Quite possible. This is *checks* cdrtools-2.01_6.[/color]

There is nothing like 2.01_6, but 2.01 is 4 years old and obsoleted by
current versions. The latest release is 2.01.01a40.

[url]ftp://ftp.berlios.de/pub/cdrecord/alpha/[/url]
[color=blue][color=green]
>> If you did not install the related software, it still compiles but you
>> will not be able to correctly work in a UTF-8 based user environment.[/color]
>
>Mine isn't UTF-8 so I wouldn't've noticed.[/color]

UTF-8 support was not needed in former times. It has been added a year ago.
You would of course need to upgrade cdrtools to a recent version first.

Given the fact that mkisofs did fix dozens of bugs since summer 2004 (this is
when 2.01 came out), I encourage you to upgrade.

Begin <6bcd5qF3aoa0uU1@mid.dfncis.de>
On 12 Jun 2008 10:47:22 GMT, Joerg Schilling <js@cs.tu-berlin.de> wrote:[color=blue]
> In article <slrng51pp4.2ur9.read_the_sig@mantell0.local>,
> jpd <read_the_sig@do.not.spam.it.invalid> wrote:[color=green]
>>Begin <6bc5c8F3536jaU1@mid.dfncis.de>
>>On 12 Jun 2008 08:34:16 GMT, Joerg Schilling <js@cs.tu-berlin.de> wrote:[color=darkred]
>>> I am not sure what you refer to, but it may be that you use a very old
>>> version of cdrecord/cdrtools.[/color]
>>
>>Quite possible. This is *checks* cdrtools-2.01_6.[/color]
>
> There is nothing like 2.01_6, but 2.01 is 4 years old and obsoleted by
> current versions. The latest release is 2.01.01a40.[/color]

That number positively inspires confidence. How much trouble is it to
increase the minor number, instead of appending more numbers? ;-)

I know it's sort-of a fad, like the four numbers mozilla now needs and
then only uses the first and the last. And people gripe about ASN.1....

Anyway, my ports/sysutils/cdrtools/Makefile is 1.70 dated 2007-04-16,
where the latest is 1.72 dated 2008-04-11, and there don't seem to have
been updates to the related distinfo file in the meantime.

The very latest available in ports is 2.01.01a39 as cdrtools-devel.
It might be a good idea to do a formal 2.02 or something so that one
doesn't need the -devel port to have something halfway recent.

[color=blue]
> Given the fact that mkisofs did fix dozens of bugs since summer 2004
> (this is when 2.01 came out), I encourage you to upgrade.[/color]

Well, I don't need it that often and the backups I take (done as iso
containing a couple of compressed tarballs) seem to work fine.

Being the reactionary conservative admin that I am, I'll stay away from
-devel ports on principle unless there is pressing need to do otherwise,
and then only grudgingly. And then there is that the old port doesn't
need libGNUGOO err libintl/libgettext.

I do think that a stable release every so often would help immensely.

--
j p d (at) d s b (dot) t u d e l f t (dot) n l .
This message was originally posted on Usenet in plain text.
Any other representation, additions, or changes do not have my
consent and may be a violation of international copyright law.