Re: The ports collection has some serious issues

[Hrant Dadivanyan]

> >
> > On Fri, Dec 16, 2016 at 6:42 AM, Peter Jeremy  wrote:
> >> On 2016-Dec-15 19:31:22 +0100, list-freebsd-ports at jyborn.se wrote:
> >> Interestingly, the most vocal proponent of deleting portmaster and
> >> portupgrade is the author/maintainer of synch.
> 
> It's not interesting at all.  Synth was in a large part created because 
> people were irrationally sticking with portmaster and more frighteningly 
> gaining new users.
> 

Please don't judge what's rational and what's not, because it's community
and when many people, even irrationally from your POV, sticking with
portmaster, then it's worth to consider and look for a way to keep it up.

> The point is that these tools are in great shape and to imply otherwise 
> needs proof.  It's portmaster that's not receiving updates.
> 

In current shape it works well for many people (and demanded by) in
community, so why should it be removed ? You can warn as much as you want
against, but you can't decide to remove.

Hrant

> John
> 
> ---
> This email has been checked for viruses by Avast antivirus software.
> https://www.avast.com/antivirus
> 
> ___
> freebsd-ports@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-ports
> To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

-- 
Hrant Dadivanyan (aka Ran d'Adi)hrant(at)dadivanyan.net
/* "Feci quod potui, faciant meliora potentes." */   ran(at)psg.com
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Gettext Issues

[@lbutlr]

> On 16 Dec 2016, at 00:22, @lbutlr  wrote:
> 
> 
>> 2014-11-30
>> Affects: users of devel/gettext (close to everyone)
>> Author: t...@freebsd.org
>> Reason: 
>>  The devel/gettext port has been split up in devel/gettext-runtime, a
>>  lightweight package containing runtime libraries, and devel/gettext-tools,
>>  a package containing developer tools.  The devel/gettext port still exists
>>  as a metaport.
>> 
>>  You must first delete the existing installation of gettext and then
>>  reinstall it.  This will break sudo, so you *must* do this in a root
>>  shell (sudo -i) if you use sudo.
> 
> I cannot imagine that gettext hasn't been updated on my system in over 2 
> years, but I seem to be having an issue that appears to be related to this 
> based on the errors.
> 
> Shared object "libintl.so.8" not found, required by "bash"
> 
> For example.
> 
> I have logged into the console directly as the root user and tried to build 
> gettext via portmaster of via make clean && make install but I get errors 
> about missing files.
> 
> pkg-static: Unable to access file 
> /usr/ports/devel/gettext-runtime/work/stage/usr/local/include/autosprintf.h: 
> No such file or directory
> 
> 
> I've tried to build gettext-runtime first, but to no avail.

To clarify, if I try to make gettext-runtime it ends with:

install  -m 0644 ABOUT-NLS 
'/usr/ports/devel/gettext-runtime/work/stage/usr/local/share/gettext'
> Compressing man pages (compress-man)
ls: 
/usr/ports/devel/gettext-runtime/work/stage/usr/local/info/autosprintf.info*: 
No such file or directory

And the error is correct, the file does not exist.


___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Irrlicht-1.8.4 sparc64 compatability?

[michael . brodeur]

I was browsing through the commit history of this package and noticed that it 
has problems compiling for sparc64? I wanted to find out if there was a 
particular reason for that?

Please let me know!


Best,

Michael Brodeur
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

CFT: OpenVPN 2.4 port update (upstream rc2) for FreeBSD

[Matthias Andree]

Greetings,

I've put up a new OpenVPN 2.4-rc2 port for FreeBSD for testing.

Get it from .

This time, it also contains the openvpn23 and openvpn23-polarssl ports
(as modified copies of what we have now) that I plan to keep for the
first quarter of 2017 and then retire, just in case.

The diff at https://reviews.freebsd.org/D8813 has been updated, too.

Cheers,
Matthias







signature.asc
Description: OpenPGP digital signature

Gettext Issues

[@lbutlr]

> 2014-11-30
> Affects: users of devel/gettext (close to everyone)
> Author: t...@freebsd.org
> Reason: 
>   The devel/gettext port has been split up in devel/gettext-runtime, a
>   lightweight package containing runtime libraries, and devel/gettext-tools,
>   a package containing developer tools.  The devel/gettext port still exists
>   as a metaport.
> 
>   You must first delete the existing installation of gettext and then
>   reinstall it.  This will break sudo, so you *must* do this in a root
>   shell (sudo -i) if you use sudo.

I cannot imagine that gettext hasn't been updated on my system in over 2 years, 
but I seem to be having an issue that appears to be related to this based on 
the errors.

Shared object "libintl.so.8" not found, required by "bash"

For example.

I have logged into the console directly as the root user and tried to build 
gettext via portmaster of via make clean && make install but I get errors about 
missing files.

pkg-static: Unable to access file 
/usr/ports/devel/gettext-runtime/work/stage/usr/local/include/autosprintf.h: No 
such file or directory


I've tried to build gettext-runtime first, but to no avail.


___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Annoying problem lzma - lzmalib

[Walter Schwarzenfeld]

correct
Next problem with liblzma. (Sorry).
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Annoying problem lzma - lzmalib

[Walter Schwarzenfeld]

Bext oribken with liblzma:

math/R
checking for lzma_version_number in -llzma... no
configure: error: "liblzma library and headers are required"
===>  Script "configure" failed unexpectedly.
Please report the problem to j...@freebsd.org [maintainer] and attach the
"/ram/usr/ports/math/R/work/R-3.3.2/config.log" including the output of the
failure of your make command. Also, it might be a good idea to provide an
overview of all packages installed on your system (e.g. a
/usr/local/sbin/pkg-static info -g -Ea).
*** Error code 1

___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: The ports collection has some serious issues

[Grzegorz Junka]

On 16/12/2016 14:45, John Marino wrote:


DragonFly has switched to Synth from poudriere as it's primary package 
builder.  That means it builds entire repositories (25,000 packages) 
biweekly on multiple servers.  It's highly used which serves as 
continuous testing.  I also use it on FreeBSD to test updates to 
ports. In fact, anyone that updates ports should use either poudriere 
testport or synth test.  (Based on evidence, it's clear that some 
people whom I won't name publicly never use the QA checks before 
committing significant changes but that's getting sidetracked).


The point is that these tools are in great shape and to imply 
otherwise needs proof.  It's portmaster that's not receiving updates.


I think adding synth as the default builder in the FreeBSD Handbook and 
deprecating portmaster and portupgrade in the documentation would go a 
long way towards letting newcomers use the ports in the proper way 
(since they are not maintained anyway). They wouldn't need to be removed 
from ports for those hardcore users who are already used to using them. 
The current presence of those tools in the official Handbook makes them 
somehow the official way of upgrading ports in FreeBSD, even if it's the 
worst way of upgrading ports possible.

Grzegorz
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

thanx for thunar crash on rename bug fix!

[Marko Cupać]

Hi,

I just wanted do say thank you to whoever fixed Thunar, or something
lower below, so that Thunar does not crash anymore when renaming
files.
-- 
Before enlightenment - chop wood, draw water.
After  enlightenment - chop wood, draw water.

Marko Cupać
https://www.mimar.rs/
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: what is the purpose of the quarterly ports branches?

[Grzegorz Junka]

On 16/12/2016 10:10, Julian Elischer wrote:

On 16/12/2016 4:01 PM, Dave Cottlehuber wrote:


On Tue, 13 Dec 2016, at 23:14, Grzegorz Junka wrote:

I heard that ports' SVN is mirrored to Github. Isn't it enough to just
create a branch or tag for each quarterly release? Even if quarterly
packages are deleted, re-building packages from such branch/tag should
allow to recreate those packages as required since the same code would
give the same packages?

These branches already exist BTW:

https://github.com/freebsd/freebsd-ports/tree/branches/2016Q3


the trouble is that the packages are deleted as soon as they are stable.


But it shouldn't be that much work to rebuild them? Setting up poudriere 
took one afternoon.

Greg
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

CIERRE FISCAL 2016

[PERSONAS MORALES]

 

En línea y en Vivo / Para todo su Equipo con una sola Conexión 

CIERRE FISCAL 2016 PARA PERSONAS MORALES
22 de diciembre - Online en Vivo - 10:00 a 13:00 y de 15:00 a 18:00 Hrs   
 
Objetivo: Identificar las principales disposiciones de la Ley del ISR, 
relacionadas con el cierre fiscal del 2016, para elaborar la declaración anual 
del ISR de personas morales del Título II de la LISR. 
¿Por qué asistir? Conocerá la determinación del ajuste anual por inflación. - 
La renta gravable para PTU y sus diferencias con la utilidad fiscal y con el 
resultado fiscal para el ISR. Los ingresos acumulables para ISR. - Las 
principales deducciones en ISR, sus requisitos, las limitadas y las prohibidas. 
 
"Pregunte por nuestra Promoción Navideña" 


TEMARIO:

1. Ingresos acumulables para ISR.

2. Papel de trabajo para determinar los ingresos contables, los del ISR y los 
de la PTU. 

3. Principales deducciones y sus requisitos para ISR y la PTU. 

4. Revisión de su contabilidad electrónica (cifras de control). 

5. Revisión de sus no deducibles de acuerdo al art 28 fracción XXX de la LISR.



...¡Y mucho más!


 
¿Requiere la información a la Brevedad?
responda este email con la palabra: 
Info - Cierre.
centro telefónico: 018002129393
 

Lic. Arturo López
Coordinador de Evento


 
¿Demasiados mensajes en su cuenta? Responda este mensaje indicando que solo 
desea recibir CALENDARIO y sólo recibirá un correo al mes. Si desea cancelar la 
suscripción, solicite su BAJA..
 

 

 

___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: The ports collection has some serious issues

[Roger Marquis]

John Marino wrote:

From porters handbook, section 12.15:
"It is possible to set DEPRECATED without an EXPIRATION_DATE (for instance, 
recommending a newer version of the port)


I'd consider that to be a bug.

So it's not a contradiction.  Ports that have a specific removal date must 
have EXPIRATION_DATE set.  If you say, well DEPRECATION implies removal, I'd 
agree, but it's at an indefinite time and I'd say that time would come when 
portmaster no longer works on the current ports tree. When that happens (and 
it probably will happen) then EXPIRATION can be set.


Non-standard uses of the term "deprecated" are problematic from a
usability perspective.  Since there is currently no deprecation messages
(apologies for the misunderstanding, I haven't used portmaster) at least
(TZ) add an install-time WARNING so we can avoid misleading potential
portmaster users (and related mailing lists threads/topics).

IMO,
Roger
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: The ports collection has some serious issues

[John Marino]

On 12/16/2016 10:09, Roger Marquis wrote:

I never understood why people went ape- over it, unless they don't
understand what "deprecated without expiration" actually means.


Perhaps then this is the crux of the issue.  From my experience
"deprecated" means only that something will not appear in a future
version of the OS.  It implies nothing about the suitability of the
software itself.  "deprecated without expiration" is a contradiction.


From porters handbook, section 12.15:
"It is possible to set DEPRECATED without an EXPIRATION_DATE (for 
instance, recommending a newer version of the port), but the converse 
does not make any sense."


So it's not a contradiction.  Ports that have a specific removal date 
must have EXPIRATION_DATE set.  If you say, well DEPRECATION implies 
removal, I'd agree, but it's at an indefinite time and I'd say that time 
would come when portmaster no longer works on the current ports tree. 
When that happens (and it probably will happen) then EXPIRATION can be set.





If Torsten drops maintainership then some sort of "strong" warning
should come with that drop.  I would be satisfied with adding a
descriptive DEPRECATED message myself.


TZ or no TZ we should drop the deprecation notice until it has an
expiration date and clarify the warning terms (ASAP).  At least that
way, when a thread like this comes up in the future, the only response
needed would be a pointer to the install message.


Which notice should we drop?  There's no DEPRECATION set now.  There's 
no warning set.  portmaster is not marked as "deprecated".


And as the handbook points out: You can't have EXPIRATION without 
DEPRECATED, but it's perfectly legal to have the reverse.  It's 
documented clearly.


John



---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: The ports collection has some serious issues

[Roger Marquis]

It is just semantics.


That may be but as illustrated in this thread people maintain
unreasonable expectations of portmaster which they often blame on the
ports subsystem.


I never understood why people went ape- over it, unless they don't
understand what "deprecated without expiration" actually means.


Perhaps then this is the crux of the issue.  From my experience
"deprecated" means only that something will not appear in a future
version of the OS.  It implies nothing about the suitability of the
software itself.  "deprecated without expiration" is a contradiction.

If Torsten drops maintainership then some sort of "strong" warning should 
come with that drop.  I would be satisfied with adding a descriptive 
DEPRECATED message myself.


TZ or no TZ we should drop the deprecation notice until it has an
expiration date and clarify the warning terms (ASAP).  At least that
way, when a thread like this comes up in the future, the only response
needed would be a pointer to the install message.

Roger
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

The ports collection has some serious issues

[John Marino]

Roger Marquis wrote

It is every week.  Consider the FreeBSD forums as well.
"misuse" and "misunderstanding" failures are attributed to the tool. Let's
stop making excuses for portmaster.  It is what it is and we've had years to
evaluate it.


If portmaster was part of base I'd agree that it should be deprecated,
however, being a port it can be afforded more leeway.  All portmaster
needs IMO is a strong WARNING message to be displayed on installation A)
enumerating some of the potential bugs and B) clarifying that portmaster
is third party software that is neither actively maintained nor
supported (or recommended?) by FreeBSD.


It is just semantics.
A "deprecated" message is just a warning.  Maybe even a "strong" 
warning.  By itself, it means nothing more than that.  Since the 
beginning, portmaster was not going to be removed, it was just going to 
carry this warning to alert users.


What you propose is what has always been proposed.  I never understood 
why people went ape- over it, unless they don't understand what 
"deprecated without expiration" actually means.  I just assumed that 
having such a warning was a scarlet letter and fans of portmaster didn't 
want the reputation defamed.


If Torsten drops maintainership then some sort of "strong" warning 
should come with that drop.  I would be satisfied with adding a 
descriptive DEPRECATED message myself.


John


---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: The ports collection has some serious issues

[Roger Marquis]

It is every week.  Consider the FreeBSD forums as well.
"misuse" and "misunderstanding" failures are attributed to the tool. Let's 
stop making excuses for portmaster.  It is what it is and we've had years to 
evaluate it.


If portmaster was part of base I'd agree that it should be deprecated,
however, being a port it can be afforded more leeway.  All portmaster
needs IMO is a strong WARNING message to be displayed on installation A)
enumerating some of the potential bugs and B) clarifying that portmaster
is third party software that is neither actively maintained nor
supported (or recommended?) by FreeBSD.

Roger
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

The ports collection has some serious issues

[John Marino]

From Kevin Oberman:

Just to add another voice of those who use portmaster on a regular basis. I
moved to portmaster about seven years ago and have has very few issues with
it. I have had issues building ports from time to time, but it's been a
long time since i hit one that was not a problem with the port... often
related to the options I use. I like that it has no dependencies. I like
that it is very stable. There are things I would like to see changed, but I
would be very upset to lose it. Since it is stable, the only way I would
lose it is if the underlying port structure changed in a way that required
work on it.

Saying that synth and poudriere are replacements for portmaster/portupgrade
simply indicate lack of familiarity with my (and others) use cases. I have
used synth and it is excellent, but not on my development system where
everything is built from source and I hope always will be. I have found
portupgrade too fragile for the reasons mentioned.  I had to clean up a
mangled database once too often. (Yes, it is a flat text db, so it can be
fixed manually, but it is NOT fun!)


"but not on my development system where everything is built from source 
and I hope always will be"


At face value, this doesn't make sense because synth is a tool for 
building everything from source, so your development system is exactly 
where it should be installed.


So you must be talking about build dependencies of synth (there are no 
run dependencies).  While I think the requirement of rebuilding synth 
from source is artificial, I've provided a very reasonable approach to 
solving this which I feel compelled to repeat for the readers of Kevin's 
post.  The solution:


Starting with a clean system:
1) install synth from binary package from official freebsd builder (a 
single package)

2) Configure synth if necessary
3) command synth to build itself
4) pkg delete synth (system is once again clean)
5) pkg add -F /path/to/synth/packages/synth-*

Now you have a system containing s/w built by itself.  On an modest 
system less than 4 years old, it might take 30 minutes at most.


So the "synth has dependencies" detraction is extremely weak.  For 
people that trust FreeBSD to provide untainted binaries, it's not an 
issue at all and for the paranoid, it's easily worked around.  Saying 
that the use of Ada limits it to the platforms it can run on natively is 
a valid detraction, but it's BUILD dependencies really aren't due to the 
availability of binary packages, the PRIMARY product of the ports tree.


RE: poudriere, it has no dependencies.  It's just as appropriate on the 
dev system and adding a jail and configuring it also takes less than 30 
minutes.  Either is very appropriate for a system that must build 
everything that is run on it.


John




---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

The ports collection has some serious issues

[John Marino]

On Fri, Dec 16, 2016 at 6:42 AM, Peter Jeremy  wrote:

On 2016-Dec-15 19:31:22 +0100, list-freebsd-ports at jyborn.se wrote:
Interestingly, the most vocal proponent of deleting portmaster and
portupgrade is the author/maintainer of synch.


It's not interesting at all.  Synth was in a large part created because 
people were irrationally sticking with portmaster and more frighteningly 
gaining new users.



I won't say "never". But I feel that both package builders (poudriere,
synth) need some more time to shake out more issues / bugs and get
into a better shape first. This isn't based on any specific problems
or bugs, more a "felleing2 based on people's feedback in the forums
and on mailing lists.


I insist that you base this on "specific problems".  Speaking for Synth, 
there are no known bugs in it.  There are no pending issues with 
existing features.  It is updated frequently.  AFAIK poudriere is 
updated regularly as well.  The above is an accusation that you 
absolutely must back up with fact because it's basically defamation.



If I was interested in package builders, I would spend some time
helping to test them. Since my interests related to FreeBSD is on
other things / tools / whatever, I spend my "FreeBSD time" on those
other things instead.


DragonFly has switched to Synth from poudriere as it's primary package 
builder.  That means it builds entire repositories (25,000 packages) 
biweekly on multiple servers.  It's highly used which serves as 
continuous testing.  I also use it on FreeBSD to test updates to ports. 
In fact, anyone that updates ports should use either poudriere testport 
or synth test.  (Based on evidence, it's clear that some people whom I 
won't name publicly never use the QA checks before committing 
significant changes but that's getting sidetracked).


The point is that these tools are in great shape and to imply otherwise 
needs proof.  It's portmaster that's not receiving updates.


John

---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: what is the purpose of the quarterly ports branches?

[Torsten Zuehlsdorff]

On 16.12.2016 11:38, Willem Jan Withagen wrote:

On 16-12-2016 11:10, Julian Elischer wrote:

On 16/12/2016 4:01 PM, Dave Cottlehuber wrote:


On Tue, 13 Dec 2016, at 23:14, Grzegorz Junka wrote:

I heard that ports' SVN is mirrored to Github. Isn't it enough to just
create a branch or tag for each quarterly release? Even if quarterly
packages are deleted, re-building packages from such branch/tag should
allow to recreate those packages as required since the same code would
give the same packages?

These branches already exist BTW:

https://github.com/freebsd/freebsd-ports/tree/branches/2016Q3


the trouble is that the packages are deleted as soon as they are stable.


It is sort of amusing/depressing/hilarious of all the flavours and ways
everybody works with ports. And I've used them all, just hard core
building, postmaster, portsnap, pouderiere...
Each has its merit, but IMHO everything is not as bad as frozen in stone
CentOS packages.


Or Ubunut or or or...

One of the big advantages of the portstree is, that you actually get new 
versions of the software and not just security-fixes.


I regularly stumble across actual bugs, which are there for years, just 
because the are not fixed by purpose. This is really really frustrating.
Bringing new versions is a big plus for the ports-tree. And if you don't 
need them you are free to stay with the old ones. And its easy enough to 
build and change everything like you want. Ever really tried this for 
various linux-distros? Its very painful.


Greetings,
Torsten
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: sysutils/php56-fileinfo exit signal Segmentation fault

[Miroslav Lachman]

to...@ciernik.sk wrote on 2016/12/16 14:12:

Hello,

this was also issue for me. I think it is conflict with svn module -
after disabling dav_svn_module problem disappeared.


Thank you for this information. It is true that machine in question have 
dav_svn_module and other machines doesn't.


I am wondering how PHP extensions can conflict with Apache module and 
how can I solve it. I cannot disable fileinfo nor svn module.


And it worked few month ago with PHP 5.5.

Miroslav Lachman

___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: sysutils/php56-fileinfo exit signal Segmentation fault

[tomas]

Hello,

this was also issue for me. I think it is conflict with svn module -
after disabling dav_svn_module problem disappeared.

Best regards,

Tomas Ciernik.



Dňa 12/16/2016 o 02:43 Miroslav Lachman napísal(a):
> I am running webmail Roundcube on many machines but on one machine file
> upload (attachment) doesn't work. I tracked it down to PHP extension
> fileinfo. Everytime I tried to upload a file I got this error in Apache
> error log:
> 
> [Fri Dec 16 02:35:27.775113 2016] [core:notice] [pid 6883] AH00052:
> child pid 6890 exit signal Segmentation fault (11)
> 
> Sometimes
> 
> [Fri Dec 16 02:36:02.110390 2016] [core:notice] [pid 6883] AH00052:
> child pid 6998 exit signal Bus error (10)
> 
> If fileinfo extension is disabled (removed ext-20-fileinfo.ini from
> /usr/local/etc/php/) upload works fine.
> I tried to change the order of extension but it doesn't change anything
> if it is last or second or anywhere in the middle of the list.
> 
> I don't know what can be wrong on this machine because all machines have
> pkgs from the same poudriere repo. All are running Apache 2.4 and PHP 5.6.
> 
> Does anybody have some idea how to solve this?
> 
> (I cannot disable fileinfo because it is needed by other websites on
> this machine)
> 
> Miroslav Lachman
> ___
> freebsd-ports@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-ports
> To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Annoying problem lzma - lzmalib

[Walter Schwarzenfeld]

some typos

I had to delete lzmalib, update rmp4 and reinstall lzmalib.


___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Annoying problem lzma - lzmalib

[Walter Schwarzenfeld]

Hallo !

Some ports fails with "undefined reference." different statement 
but  points to lzma.


Mostly I can solve it with adding LDFLAGS+=   -L/usr/lib -llzma to 
the Makefile. Today it was an update

of rpm4. I had to delete lzmali, update rmp4 and reinstall rpm4.

In summary I have10 ports  with the lzma problem. One of the two 
solution helps, but it is annoying.


Could someone solve the pathproblem   with lzma and lzmalib.
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: what is the purpose of the quarterly ports branches?

[Willem Jan Withagen]

On 16-12-2016 11:10, Julian Elischer wrote:
> On 16/12/2016 4:01 PM, Dave Cottlehuber wrote:
>>
>> On Tue, 13 Dec 2016, at 23:14, Grzegorz Junka wrote:
>>> I heard that ports' SVN is mirrored to Github. Isn't it enough to just
>>> create a branch or tag for each quarterly release? Even if quarterly
>>> packages are deleted, re-building packages from such branch/tag should
>>> allow to recreate those packages as required since the same code would
>>> give the same packages?
>> These branches already exist BTW:
>>
>> https://github.com/freebsd/freebsd-ports/tree/branches/2016Q3
> 
> the trouble is that the packages are deleted as soon as they are stable.

It is sort of amusing/depressing/hilarious of all the flavours and ways
everybody works with ports. And I've used them all, just hard core
building, postmaster, portsnap, pouderiere...
Each has its merit, but IMHO everything is not as bad as frozen in stone
CentOS packages. Where I have the feeling that I'm years behind on some
of the stuff, and the only way out is to start gathering and build
manually. Ports is way more comfortable.

For the Q-branches:
Storage could be an issue, but isn't this why we have ZFS with
snapshot/clones Just at the end of a Q freeze both ports and
distfiles in a snapshot.

--WjW


___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: (In)Stability of the Quarterly Branch

[Vlad K.]

On 2016-12-16 11:08, Torsten Zuehlsdorff wrote:


There are two problems with this:
1) Many ports have no maintainer
2) Even more ports have no tests at all



We can't have our cake and eat it :)

Obviously, a STABLE repo would have to be a subset of ports, not all 26k 
of them. The criteria I spoke of in the original post would include that 
each port has a valid maintainer. Maintainer TIMEOUTS would be monitored 
and port kicked out if the maintainer is gone.


For starters, we'd have to enumerate all the ports that have stable 
upstreams. For example, RoundCube supports both the new 1.2.x repo and 
the old, legacy 1.1.x. That means 1.1.x could've been added to the 
STABLE repo and maintained until it EOLs.


Second, ports that do not obey some reasonable versioning scheme, eg. 
major version changes MAY break backwards compatibility, minor MUST not, 
and major.minor.point MUST be only bugfixes and security. can be added 
ONLY and ONLY if the MAINTAINER commits to manually checking every 
change and making sure only security and bugfixes are backported.


Third, ports with no unit tests... well.. I don't know how many are 
there, but perhaps we can make a list of "strategically important" ports 
for servers and maybe desktops, and those that are strategically 
important but have no unit tests, would go in, but would require an 
active maintainer committed to do run tests. I'm sure such a list would 
be bikeshed into oblivion, but we could at least try...


Fourth. It'd be ideal if Poudriere could grow a function that:

a) runs port's unit tests
b) permutates OPTIONS and for each re-runs the build + unit test. Broken 
combinations can be automatically marked as BROKEN.


Now... automatically:

b.1) a patch is automatically generated but a human has to review and 
commit
b.2) the testing infrastructure autocommits (I'm sure portmgr would 
object to this)
b.3) we create a new "stability" database like vuxml which these 
automated tests can automatically populate


Brainstorming here, critique welcome!



--

Vlad K.
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: what is the purpose of the quarterly ports branches?

[Julian Elischer]

On 16/12/2016 4:01 PM, Dave Cottlehuber wrote:


On Tue, 13 Dec 2016, at 23:14, Grzegorz Junka wrote:

I heard that ports' SVN is mirrored to Github. Isn't it enough to just
create a branch or tag for each quarterly release? Even if quarterly
packages are deleted, re-building packages from such branch/tag should
allow to recreate those packages as required since the same code would
give the same packages?

These branches already exist BTW:

https://github.com/freebsd/freebsd-ports/tree/branches/2016Q3


the trouble is that the packages are deleted as soon as they are stable.



A+
Dave
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"



___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: (In)Stability of the Quarterly Branch

[Torsten Zuehlsdorff]

On 16.12.2016 08:24, David Demelier wrote:

2016-12-15 17:25 GMT+01:00 Matthew Seaman :

On 2016/12/15 16:01, Olivier Duchateau wrote:

The problem is that there are no tests in FreeBSD ports. All source
based systems I've tested: pkgsrc, FreeBSD ports, OpenBSD, Gentoo;
FreeBSD is the one that have the most instability. Not to mention
committers that commit without testing the port, just look at
www/redmine to get your point of view on that issue.



Are your serious when you said, there're no tests on FreeBSD ports. I
can tell you Xfce ports are tested with FreeBSD i386 9.3 and amd64
11.0 machines (on real hardware, no virtualization), and on poudriere
with Gtk+ 3.20 (port version is not not in ports tree, it's defaut
toolkits for the next stable release 4.14).

For the LXQt desktop is the same thing (tested with official ports
tree Qt5 and which one in plasma5 branch (on KDE repository).

I'm also working on the Pantheon desktop (desktop environment of
Elementary OS, I use Vala 0.30.2 and Vala 0.34.4, in order to test
stability of applications.

I use also OpenBSD macppc, it's piece of shit. WebKit browers are
broken, Xfce components crash often, stable branch is outdated, fix
are not propagated in stable branch. Personally I prefer the FreeBSD
scheme, because I'm sure it's quite stable.


Most port committers will run compile tests any time they update a port:
the better ones will test compilation on all supported FreeBSD versions
and all hardware architectures they have access to (ie. generally i386
and amd64).


I'm not talking about being sure that the port builds, but that the
software works. This is a next step that is too often forgotten. For
example I remember several years ago having a problem with
audio/mumble. The port was building fine, the window opened fine but
it was impossible to speak because there was a problem regarding the
CELT libraries IIRC.


I really support this, but from a committer perspective its quite 
impossible. Often enough we just have no idea how the port needs to work 
- so we must trust the maintainer. But too often there is none.



Additionally the package build cluster will rebuild any modified ports
within a few days for all of the OS versions and architectures the
project tries to provide ports for: that's yet another level of
validating the coding of the port itself.

However, I believe the OP's point is that *we do not routinely run the
software's own built-in regression tests for the packages we succeed in
building*.  This is something that is slowly coming.  For instance, you
can run 'make test' for many python, ruby or perl packages and see those
tests being run.  TEST_DEPENDS is pretty much standardized as the way to
install dependencies required for testing nowadays.



Yes, I fully understand the requirements of such tests. I just would
like that maintainers test the port by building it and *by running*
them. This is time consuming for sure, but if the maintainers have no
time, then just keep an old but fully working version :-)


There are two problems with this:
1) Many ports have no maintainer
2) Even more ports have no tests at all

I'm a big fan for testing. I test every software i wrote and in every 
firm i worked i had the lowest bug count. But if you try to teach other 
people to write tests too you hit a hard wall...


So we need to address multiple problems. I'm currently working on an 
project to improve the management of the ports-tree. Hopefully i can 
free some time for all so we can test the runtime much better.


Greetings,
Torsten
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: (In)Stability of the Quarterly Branch

[Julian Elischer]

On 15/12/2016 9:43 PM, Torsten Zuehlsdorff wrote:

On 15.12.2016 14:16, David Demelier wrote:

[...]


What I want: a ports tree that matches the FreeBSD version like
OpenBSD. You have FreeBSD 11.0? You get a ports tree for that version
specifically. No major update, no breaking changes. Just bug fixes.
That will also simplify a lot FreeBSD ports by not having thousands of
conditional checking the FreeBSD version.


That what i really, really, really NOT want. I have regular problems 
with our admins because of that. You want a specific version of an 
software? No problem: just install a specific version of your 
operation system. Need two of them, but they are not in this bundle? 
To bad, than you need a new server. This is an daily-base scenario i 
really don't want to port to FreeBSD.


  the problem I have is that on the one machine the UI people want 
node-x.y and the VM configuration people need boto-a.b, but boto-a.b 
and node-x.y don't exist at the same time in the ports tree and there 
is no snapshot of packages when they exist..  it's like saying "that 
dinosaur and this dinosaur never met because one was Jurassic and the 
other was Triassic. To make it worse the packages taken from different 
times insist on installing different versions of some other package, 
so I can't just take packages from different times (because they 
OVERSPECIFY their dependencies,, it may work but I don't get the 
chance because the install balks).


So I'm left with compiling..
If I use poudriere I need otmake a synthetic tree with different 
revisions, bus the API for the ports tree moves so fast that often you 
cant; even do that because one requires mk/uses/python.mumble and 
theother wants some incompatible other  change.


So the problems I see are
1/ over specification of dependencies, leading to artificial 
requirements to upgrade things.
2/ leaf dependencies having too many options, leading to exponential 
fan-out of dependencies.
3/ API changes too frequent, and not enough care taken thinking about 
what happens if one needs to get a back-rev version of something.
4/ ports not always noticing when a dependency package is installed 
and compiling the dependency anyhow.


here's an example;
'tracker' is a simple package.
but requires the following makefiles to be in sync API wise.

# Build dependencies
TRACKER_DEP_PORTS:= devel/desktop-file-utils devel/gettext-tools 
devel/gmake graphics/gtk-update-icon-cache
TRACKER_DEP_PORTS+= print/indexinfo textproc/intltool devel/gettext 
lang/perl5.20 lang/python27 graphics/poppler
TRACKER_DEP_PORTS+= devel/gobject-introspection textproc/libxslt 
devel/pkgconf multimedia/gstreamer1-plugins
TRACKER_DEP_PORTS+= devel/xdg-utils converters/o3read 
graphics/poppler-utils www/w3m
TRACKER_DEP_PORTS+= devel/desktop-file-utils 
graphics/gtk-update-icon-cache multimedia/gstreamer1-plugin
TRACKER_DEP_PORTS+= devel/dbus-glib mail/gmime26 sysutils/hal 
textproc/raptor sysutils/e2fsprogs
TRACKER_DEP_PORTS+= misc/e2fsprogs-libuuid devel/icu 
multimedia/libmediaart devel/librest
TRACKER_DEP_PORTS+= multimedia/totem-pl-parser audio/flac 
audio/libvorbis textproc/libcue
TRACKER_DEP_PORTS+= audio/libogg audio/taglib graphics/poppler-glib 
graphics/libgxps
TRACKER_DEP_PORTS+= devel/libgsf textproc/exempi textproc/wv 
graphics/libexif
TRACKER_DEP_PORTS+= graphics/giflib graphics/png graphics/tiff 
devel/gettext-runtime
TRACKER_DEP_PORTS+= accessibility/atk graphics/gdk-pixbuf2 
devel/glib20 x11-toolkits/gtk30
TRACKER_DEP_PORTS+= textproc/libxml2 x11-toolkits/pango 
archivers/libarchive databases/sqlite3
TRACKER_DEP_PORTS+= devel/libffi devel/pcre converters/libiconv 
graphics/cairo devel/bison
TRACKER_DEP_PORTS+= lang/python2 x11/libXext x11/libXrender x11/libX11 
x11/libXinerama
TRACKER_DEP_PORTS+= x11/libXi x11/libXrandr x11/libXcursor 
x11/libXfixes x11/libXdamage
TRACKER_DEP_PORTS+= x11/libXcomposite x11-toolkits/libXt 
graphics/jasper graphics/jbigkit graphics/jpeg-turbo
TRACKER_DEP_PORTS+= x11-fonts/fontconfig x11-fonts/libXft 
print/freetype2 print/harfbuzz x11-fonts/xorg-fonts-truetype
TRACKER_DEP_PORTS+= x11-fonts/encodings misc/shared-mime-info 
misc/hicolor-icon-theme textproc/p5-XML-Parser security/libgcrypt
TRACKER_DEP_PORTS+= multimedia/gstreamer1 misc/iso-codes devel/orc 
devel/dbus multimedia/v4l_compat
TRACKER_DEP_PORTS+= sysutils/policykit devel/libvolume_id 
sysutils/consolekit misc/pciids sysutils/gnome_subr
TRACKER_DEP_PORTS+= sysutils/dmidecode ftp/curl textproc/gtk-doc 
lang/vala security/ca_root_nss
TRACKER_DEP_PORTS+= devel/libsoup-gnome multimedia/libquvi09 
textproc/expat2 devel/cmake graphics/lcms2
TRACKER_DEP_PORTS+= graphics/openjpeg15 graphics/poppler-data 
graphics/libwmf accessibility/at-spi2-atk graphics/libepoxy
TRACKER_DEP_PORTS+= graphics/colord print/cups 
x11-themes/adwaita-icon-theme textproc/xmlto x11/xprop

TRACKER_DEP_PORTS+= x11/xset devel/boehm-gc
TRACKER_DEP_PORTS+= misc/dejagnu x11/xcb-util-renderutil 
graphics/libGL graphics/libEGL x11/glproto

Re: The ports collection has some serious issues

[Andrea Venturoli]

On 12/16/16 07:42, Torfinn Ingolfsen wrote:


FWIW, I'm a happy portupgrade user.


Me too.

I just frequently run into a bug: when icu is updated, somehow the old 
libraries are not saved and all ports depending on icu break.

Now I know that I should take care with that single port.

Also, I wish I would be to be able to "portupgrade" a jail, i.e. running 
portupgrade in base and update the ports inside jails, without the need 
to install portupgrade (and ruby and every other dependency) in the jail.




That said, I've been considering the move to poudriere, but that's a low 
priority task.


 bye
av.

___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: The ports collection has some serious issues

[Torsten Zuehlsdorff]

On 15.12.2016 18:43, Miroslav Lachman wrote:

John Marino wrote on 2016/12/15 17:46:


[1] I've got it on my todo list to provide a new method that would
eliminate the "my builder just rebuilt 150 packages, but pkg(8) only
upgraded 2 packages" issue that some users don't want to see.  It's a
lot more complicated than the conservative yet bulletproof approach
currently used by poudriere and synth.


This is interesting case - we are running own Poudriere repo and I am
fine with it. But I am a bit nervous when I know 150 packages was
rebuilt and just 2 upgraded by pkg. In this case I want pkg to update
(reinstall) all of them.
If something changed so that 150 packages must be rebuilt why pkg
doesn't reinstall them? Isn't it the possible place for problems after
upgrade?


Not really. I found the following explanation from babt about this behavior:
https://lists.freebsd.org/pipermail/freebsd-ports/2015-January/097569.html

Since its from last year, it is maybe outdated. But if this issue still 
stands, its worth addressing it.


Greetings,
Torsten
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: what is the purpose of the quarterly ports branches?

[Dave Cottlehuber]

On Tue, 13 Dec 2016, at 23:14, Grzegorz Junka wrote:
> I heard that ports' SVN is mirrored to Github. Isn't it enough to just 
> create a branch or tag for each quarterly release? Even if quarterly 
> packages are deleted, re-building packages from such branch/tag should 
> allow to recreate those packages as required since the same code would 
> give the same packages?

These branches already exist BTW:

https://github.com/freebsd/freebsd-ports/tree/branches/2016Q3

A+
Dave
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"