Re: The ports collection has some serious issues

[Dave Cottlehuber]

On Mon, 12 Dec 2016, at 17:20, Julian Elischer wrote:
> > Have you considered using things like poudriere that would allow you to 
> > build
> > your own repository with your own set of packages and options.
> >
> > You will benefit:
> > - ability to use pkg for your upgrades
> > - ability to use customize your packages
> > - safe rebuild process (in case of broken ABI)
> >
> > Best regards,
> > Bapt
> I'm actually slowly moving to this if I can work out how to specify my 
> own chroot image, and a few other things I need to tweak. (my own sets 
> of patches to add).

Hi Julian,

I've been doing this with poudriere + pkg + git for a couple of years
now very happily, using a lagging ports checkout (similar to the
quarterly branch but taken at our convenience), and git rebasing our
custom patches so they "float" up to the top. We're using it at
iwantmyname.com now as well.

The guts of it is:

- use poudriere as usual but with a git-backed /usr/ports
- store custom patches in /usr/ports and push to
https://github.com/ideegeo/ports/ until they get committed in FreeBSD
ports tree
- git rebase periodically to pull in shiny bits from
git://github.com/freebsd/freebsd-ports master branch
- ansible pkg triggers a poudriere run whenever we add a new package to
the list
- these are made available via our pkg repo to our servers
- in practice, ansible is used to set up the whole stuff from scratch
including letsencrypt certs for the https://pkg.example.org/ but these
are the pre-automation steps I started with.

Here are the raw notes from our wiki and that should be sufficient for
you to try this out on a test VM somewhere.  I assume I've forgotten
stuff or made errors but promise to blog it over Christmas with a longer
explanation.

https://gist.github.com/dch/ec2693c051c66dcd2f17b30fc575a910

BTW I'm not exactly sure what you mean about a custom chroot image, but
I imagine you can fiddle with the poudriere base in
zroot/poudriere/jails/11_amd64 to your heart's content and it will be
used during the build.

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"

Re: The ports collection has some serious issues

[Kevin Oberman]

On Thu, Dec 15, 2016 at 9:42 PM, Peter Jeremy  wrote:

> On 2016-Dec-15 19:31:22 +0100, list-freebsd-po...@jyborn.se wrote:
> >On Thu, Dec 15, 2016 at 01:18:05PM -0500, George Mitchell wrote:
> >> On 12/15/16 09:40, Warren Block wrote:
> >> > On Thu, 8 Dec 2016, Matt Smith wrote:
> >> >
> >> >> On Dec 08 05:16, Daniil Berendeev wrote:
> >> >>>
> >> >>> Although portmaster is not releated to the FreeBSD project and is an
> >> >>> outside tool, there aren't any alternatives from the project
> itself. So
> >> >>> use it or die. Not a nice situation.
> >> >>
> >> >> People have been trying to get portmaster deprecated and removed from
> >> >> the handbook but have met with resistance.
> >> >
> >> > Well, yes.  Because it works, has no dependencies, and there is no
> >> > equivalent replacement.  [...]
> >>
> >> Warren, you have hit the nail on the head.  -- George
> >
> >+1
> >
> >I never have problems with portmaster.
>
> I don't know about never - I think I managed to get it into a dependency
> loop once - but I've never had any issues that I could not resolve or
> that would entice me to look at an alternative.
>
> >(But portupgrade could at times be an utter mess,
> >I never looked back after switching to portmaster
> >many years ago.)
>
> Likewise, portupgrade would explode and shower my system with bits of
> corrupt database to often for comfort.  At least part of that was caused
> by portupgrade depending on quite a few other ports and getting confused
> when it updated things whilst it was using them.
>
> >And I'm not at all interested in running poudriere
> >or synth, thank you.
>
> Interestingly, the most vocal proponent of deleting portmaster and
> portupgrade is the author/maintainer of synch.
>
> --
> Peter Jeremy
>

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!)
--
Kevin Oberman, Part time kid herder and retired Network Engineer
E-mail: rkober...@gmail.com
PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683
___
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

[Torfinn Ingolfsen]

On Fri, Dec 16, 2016 at 6:42 AM, Peter Jeremy  wrote:
> On 2016-Dec-15 19:31:22 +0100, list-freebsd-po...@jyborn.se wrote:
>>On Thu, Dec 15, 2016 at 01:18:05PM -0500, George Mitchell wrote:
>
>>(But portupgrade could at times be an utter mess,
>>I never looked back after switching to portmaster
>>many years ago.)
>
> Likewise, portupgrade would explode and shower my system with bits of
> corrupt database to often for comfort.  At least part of that was caused
> by portupgrade depending on quite a few other ports and getting confused
> when it updated things whilst it was using them.
>

FWIW, I'm a happy portupgrade user.
Yes - sometimes it breaks, but it is quite rare, and I am able to fix
the breakage when it happens.
So for me it is "good enough".


>>And I'm not at all interested in running poudriere
>>or synth, thank you.
>
> Interestingly, the most vocal proponent of deleting portmaster and
> portupgrade is the author/maintainer of synch.

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.
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.

HTH
-- 
Regards,
Torfinn Ingolfsen
___
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

[Peter Jeremy]

On 2016-Dec-15 19:31:22 +0100, list-freebsd-po...@jyborn.se wrote:
>On Thu, Dec 15, 2016 at 01:18:05PM -0500, George Mitchell wrote:
>> On 12/15/16 09:40, Warren Block wrote:
>> > On Thu, 8 Dec 2016, Matt Smith wrote:
>> > 
>> >> On Dec 08 05:16, Daniil Berendeev wrote:
>> >>>
>> >>> Although portmaster is not releated to the FreeBSD project and is an
>> >>> outside tool, there aren't any alternatives from the project itself. So
>> >>> use it or die. Not a nice situation.
>> >>
>> >> People have been trying to get portmaster deprecated and removed from
>> >> the handbook but have met with resistance.
>> > 
>> > Well, yes.  Because it works, has no dependencies, and there is no
>> > equivalent replacement.  [...]
>> 
>> Warren, you have hit the nail on the head.  -- George
>
>+1
>
>I never have problems with portmaster.

I don't know about never - I think I managed to get it into a dependency
loop once - but I've never had any issues that I could not resolve or
that would entice me to look at an alternative.

>(But portupgrade could at times be an utter mess,
>I never looked back after switching to portmaster
>many years ago.)

Likewise, portupgrade would explode and shower my system with bits of
corrupt database to often for comfort.  At least part of that was caused
by portupgrade depending on quite a few other ports and getting confused
when it updated things whilst it was using them.

>And I'm not at all interested in running poudriere
>or synth, thank you.

Interestingly, the most vocal proponent of deleting portmaster and
portupgrade is the author/maintainer of synch.

-- 
Peter Jeremy


signature.asc
Description: PGP signature

Re: The ports collection has some serious issues

[Daniil Berendeev]

> Here, it doesn't look like that. Don't forget that /usr/ports/distfiles
> accumulates old versions and must be manually cleaned out from time to
> time.  portmaster has a couple of options to remove distfiles that are
> not needed.
> 
> % du -hd0 /usr/ports
> 8.1G/usr/ports
> % du -hd0 /usr/ports/distfiles
> 6.5G/usr/ports/distfiles
> 
> After copying that to /tmp and deleting distfiles entirely:
> 
> % du -hd0 /tmp/usr/ports
> 1.4G/tmp/usr/ports

Well, I know that, I were trying to tell that portsnap(8) is fetching
HEAD by default and I didn't find any way to change that behavior. So
the only way to pick another branch would be fetching the entire svn
repository. I need it for development purposes also, so anyway I'd have
to do that.

But the size of the svn repository causes pure pain. Subversion is not
intended for development style that requires keeping lots of branches
and tags. Everyone knows that. At the moment, the repository takes
~/> du -h ports-fbsdsvn/
 42Gports-fbsdsvn/

In git, Mercurial, bazaar, well, any modern version control system you
can create tons of branches, tags without wasting space or time.

-- 
Cheers~

PGP key fingerprint:
07B3 2177 3E27 BF41 DC65  CC95 BDA8 88F1 E9F9 CEEF

You can retrieve my public key at pgp.mit.edu.
___
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"

sysutils/php56-fileinfo exit signal Segmentation fault

[Miroslav Lachman]

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"

Re: The ports collection has some serious issues

[Michelle Sullivan]

Matthieu Volat wrote:

On Thu, 15 Dec 2016 19:31:22 +0100
list-freebsd-po...@jyborn.se wrote:


On Thu, Dec 15, 2016 at 01:18:05PM -0500, George Mitchell wrote:

On 12/15/16 09:40, Warren Block wrote:

On Thu, 8 Dec 2016, Matt Smith wrote:


On Dec 08 05:16, Daniil Berendeev wrote:

Although portmaster is not releated to the FreeBSD project and is an
outside tool, there aren't any alternatives from the project itself. So
use it or die. Not a nice situation.

People have been trying to get portmaster deprecated and removed from
the handbook but have met with resistance.

Well, yes.  Because it works, has no dependencies, and there is no
equivalent replacement.  [...]

Warren, you have hit the nail on the head.  -- George

+1

I never have problems with portmaster.
(But portupgrade could at times be an utter mess,
I never looked back after switching to portmaster
many years ago.)

And I'm not at all interested in running poudriere
or synth, thank you.


It seems that if people happy with portmaster keep silent, others will assume 
it's okay to try to dismiss it;


Yup


  so here am I, happy with portmaster.


Don't worry, the people that have the power will dismiss it when they 
deem you need to "upgrade" to using synth or poudreire... oh and don't 
worry they'll remove distfiles and the previous 4 versions of the 
distfiles so that you can't keep your own local copy running, especially 
if you publish how to use it yourself.




I could switch to something else that is feature wise similar; but if it would 
not written in some quasi-obselete/niche/hipster programing language or involve 
admin/config tasks like creating repos.

Until a challenger appears, I'm just going to use and recommend portmaster.


Same.

Regards,

Michelle
___
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

[Mark Millard]

John Marino freebsd.contact at marino.st on Thu Dec 15 16:46:54
UTC 2016 wrote:

> For i386 and amd64 users, synth does not require more resources than 
> portmaster.  People on those platforms can't use "resources" as a reason 
> not to use Synth.  From what I can tell, portmaster people hate what 
> they consider unnecessary rebuilds which both poudriere and synth 
> (currently [1]) do, but it's this avoidance of rebuilds that cause all 
> their problems.

Also on Thu Dec 15 16:00:47 UTC 2016:

> Anybody with a machine that doesn't have a resources to run poudriere or 
> synth should not be building packages on that machine.  Veterans have 
> the option to use portmaster in a case like that, but it's not something 
> that should be suggested to newbies.

Note: My FreeBSD usage is not from any of the main families of usage. Do
  not think that I expect things to be biased for my use. My kind
  of context may well be implicitly not intended to be covered by the
  above.


I wonder if build tool recommendations need some breakout by
user categories rather than one grand overall recommendation.
This might be just a note of "no specific recommendation" for
some category(s).

I use my context below as a potential example.

I primarily experiment with self hosting FreeBSD activities on powerpc64,
powerpc, armv6/armv7, and aarch64, reporting issues that I find. For the
powerpc family this has focused on fairly modern clang usage for
buildworld and buildkernel -- as well as building ports. This tends to
fit me with "developer" and less with "user" in some respects.

If synth was buildable and usable on powerpc64, powerpc, armv6/armv7, 
and aarch64 I likely would have tried it. (I do not want to be using
different self-hosting techniques per TARGET_ARCH but instead use
one set of techniques on all.)

Building synth would take up more time and space than portmaster but
I could have tolerated such. For the SD card contexts I tend to
have an SSD for the root file system. This likely is uncommon. Only
the old powerpc's have fewer than 4 cores/processors supported by
FreeBSD: one armv7 has 8 but FreeBSD supports only 4. buildworld with
-j 4 or so does take a long time on the armv7 machines (for example).
Of course there are large differences in performance compared to modern
amd64's.

When I tried portupgrade over a time I had problems with ruby in these
environments. (amd64 went okay.) I eventually backed off, figuring I'd
retry after some significant time in case they were temporary issues.

Other than backups/recovery media I have one powerpc64 SSD for experiments,
one powerpc SSD, one armv7 SSD (and an SD card) per single board computer
type, and the same for the one aarch64 single board computer. Definitely
not build-once/distribute-many generally. (But the armv7 context could do
a little of that as I'm currently structuring things.)

After "pkg autoremove" "portmaster --list-origins" lists 20-30 or so
ports in each case. Before the autoremove "pkg info | wc" is under 100
as I remember. I sometimes have patches to ports involved when someone
asks me to test such for something that I've reported. And because of
binutils problems for powerpc64 I use older versions from svn in the
contexts that I deal with targeting powerpc64's (that includes the
devel/powerpc64-binutils slave port). For a time devel/powerpc64-gcc
could not finish buildworld unless I used an older vintage from svn.

I really do use devel/powerpc64-gcc and devel/powerpc64-binutils and
devel/powerpc64-xtoolchain-gcc on a powerpc64: a "self hosted cross
build" of sorts. Getting devel/powerpc64-gcc installed on a powerpc64
requires a work-around because it is not a true cross-build and
some things are not the same if the target architecture is not
distinct: I'm operating outside the intended usage model. The work
around involves copying/moving some files to the right place/name
in the staging area so that installation can find them and complete.

[I also use amd64 FreeBSD under virtualbox in another operating
system. This context has more to it but is still likely less than
is typical.]

[Ignoring amd64:] If I had been able to use synth on the variety of
machines it would appear that the contribution of my time preferences
might have eventually stopped my use. (Not the number of ports
rebuilt as such but the systematic time spent.) "Might" because for
my context it is not obvious up front what my judgement might be
after a trail period.

I'm not sure what I would have done about issues like
devel/powerpc64-gcc being built and installed on a powerpc64
machine and needing a work around. Or testing patches for ports.
I did not try to figure it out since I since I discovered
synth was not an option first.

I configure to avoid "disk" space issues generally (SSD root
filesystems normally, with plenty of space).

RAM varies from 1G to 2G Bytes over the armv7's, aarch64, and some
powerpc's, but for powerpc64 there is more RAM: 8G, 12G, or 16G

can somebody commit this fix for isc-dhcp43 port?

[Miroslav Lachman]

net/isc-dhcp43-server: rc script does not play nice with service -e
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=213463

Reported at October, added patch and poudriere log but still uncommitted.
Reminded at November and? Still not committed.

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"

CFT: OpenVPN 2.4 port update for FreeBSD

[Matthias Andree]

Greetings,

I've put up an OpenVPN 2.4-rc1 port for FreeBSD up for testing.

Get it from https://people.freebsd.org/~mandree/openvpn-2.4.r1-v1.tar.xz

Or review the diff at https://reviews.freebsd.org/D8813

Cheers,
Matthias





signature.asc
Description: OpenPGP digital signature

Re: No port should need root for make fetch

[Peter Jeremy]

On 2016-Dec-15 09:43:51 +0100, Mathieu Arnold  wrote:
>Le 14/12/2016 à 06:17, Peter Jeremy a écrit :
>> On 2016-Dec-13 21:32:36 +0100, "Julian H. Stacey"  wrote:
>>> IMO No port should need root for 
>>> cd /usr/ports; make -i fetch
>> In a stock FreeBSD install, all ports require root to both fetch and build.
>> You have customised your system in a non-standard way so you are getting
>> non-standard behaviour which doesn't match you expectations.
>
>That is plain not true.

By default, /usr/ports/distfiles is mode 0775 root:wheel and the only member
of wheel is root.  Fetching a port requires writing to /usr/ports/distfiles,
hence root is the only user that can fetch distfiles.

Likewise, by default, ports are built it /usr/ports/CATEGORY/NAME/work.
/usr/ports/CATEGORY/NAME is only writable by root so only root can create
the work directory in which to build ports.

If you change the above defaults (which I suspect most people do) then you
are correct that only a handful of ports need root to fetch or build (and
I think that is still too many) - but I explicitly specified "stock install".

-- 
Peter Jeremy


signature.asc
Description: PGP signature

Re: The ports collection has some serious issues

[Matthieu Volat]

On Thu, 15 Dec 2016 19:31:22 +0100
list-freebsd-po...@jyborn.se wrote:

> On Thu, Dec 15, 2016 at 01:18:05PM -0500, George Mitchell wrote:
> > On 12/15/16 09:40, Warren Block wrote:
> > > On Thu, 8 Dec 2016, Matt Smith wrote:
> > > 
> > >> On Dec 08 05:16, Daniil Berendeev wrote:
> > >>>
> > >>> Although portmaster is not releated to the FreeBSD project and is an
> > >>> outside tool, there aren't any alternatives from the project itself. So
> > >>> use it or die. Not a nice situation.
> > >>
> > >> People have been trying to get portmaster deprecated and removed from
> > >> the handbook but have met with resistance.
> > > 
> > > Well, yes.  Because it works, has no dependencies, and there is no
> > > equivalent replacement.  [...]
> > 
> > Warren, you have hit the nail on the head.  -- George
> 
> +1
> 
> I never have problems with portmaster.
> (But portupgrade could at times be an utter mess,
> I never looked back after switching to portmaster
> many years ago.)
> 
> And I'm not at all interested in running poudriere
> or synth, thank you.
> 

It seems that if people happy with portmaster keep silent, others will assume 
it's okay to try to dismiss it; so here am I, happy with portmaster.

I could switch to something else that is feature wise similar; but if it would 
not written in some quasi-obselete/niche/hipster programing language or involve 
admin/config tasks like creating repos.

Until a challenger appears, I'm just going to use and recommend portmaster.

Happy bsding everybody

-- Matthieu


pgplStNvzBqaD.pgp
Description: OpenPGP digital signature

Re: The ports collection has some serious issues

[list-freebsd-ports]

On Thu, Dec 15, 2016 at 01:18:05PM -0500, George Mitchell wrote:
> On 12/15/16 09:40, Warren Block wrote:
> > On Thu, 8 Dec 2016, Matt Smith wrote:
> > 
> >> On Dec 08 05:16, Daniil Berendeev wrote:
> >>>
> >>> Although portmaster is not releated to the FreeBSD project and is an
> >>> outside tool, there aren't any alternatives from the project itself. So
> >>> use it or die. Not a nice situation.
> >>
> >> People have been trying to get portmaster deprecated and removed from
> >> the handbook but have met with resistance.
> > 
> > Well, yes.  Because it works, has no dependencies, and there is no
> > equivalent replacement.  [...]
> 
> Warren, you have hit the nail on the head.  -- George

+1

I never have problems with portmaster.
(But portupgrade could at times be an utter mess,
I never looked back after switching to portmaster
many years ago.)

And I'm not at all interested in running poudriere
or synth, thank you.

Peter
___
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

[George Mitchell]

On 12/15/16 09:40, Warren Block wrote:
> On Thu, 8 Dec 2016, Matt Smith wrote:
> 
>> On Dec 08 05:16, Daniil Berendeev wrote:
>>>
>>> Although portmaster is not releated to the FreeBSD project and is an
>>> outside tool, there aren't any alternatives from the project itself. So
>>> use it or die. Not a nice situation.
>>
>> People have been trying to get portmaster deprecated and removed from
>> the handbook but have met with resistance.
> 
> Well, yes.  Because it works, has no dependencies, and there is no
> equivalent replacement.  [...]

Warren, you have hit the nail on the head.  -- George

___
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"

Auditorías a través del Buzón Tributario

[cuándo es obligatoria la contabilidad electrónica]

 

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

Auditorías a través del Buzón Tributario
29 de diciembre - Online en Vivo - 10:00 a 13:00 Hrs   
 
A través de esta Capacitación Online en Vivo entérese cuáles son los sectores 
involucrados, en qué consisten dichas auditorías, a qué segmentos van dirigidas 
y cómo se tendrán que resolver las inconformidades en términos del Buzón 
Tributario. Descubra cómo las personas físicas y los pequeños negocios 
inscritos en el Régimen de Incorporación Fiscal (RIF) son los sectores que más 
han resentido los cambios entrados en vigor en 2014, ya que todavía hay 
carencias técnicas y tecnológicas. 
"Pregunte por nuestra Promoción Navideña" 


TEMARIO: 

1. Qué son los trámites por Buzón Tributario y Auditorías Electrónicas del SAT.

2. Marco legal del Buzón Tributario y las Auditorías.

3. A partir de cuándo es obligatoria la contabilidad electrónica.

4. Vigencia de la notificación vía e-mail: Se incumple con el pago de impuestos 
por no tener acceso a internet.




...¡Y mucho más!


 
¿Requiere la información a la Brevedad?
responda este email con la palabra: 
Info - Buzón.
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

[Miroslav Lachman]

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?


Mirek
___
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

[Iblis Lin]

I want to talk about another issue: the testing of ports framework

We usually test our ports via poudriere or synth. We have a greate ports
framework to help us build software, and we only need to write a few
lines of code to leveage it. But ...  where is the testing of the framework ?
Those code under Mk/* is quite complex nowaday, and the requirement is
keeping changing (for example, more and more new languages appear,
helpers need to be added into ports framework). This will be a big barrier
for maintenance. Is time to build a next generation framework?

I think about this issue for a few weeks already, but still not get a good
answer. I only sorted out some principles and want to hear more
feedback:

1) Select a modern scripting language
Lots of testing methodology implemented in those languages.
Most of them are high-level. The cost of maintenance (hopefully)
reduce. So, I think this is a good starting point.

2) Not to abandon tons of Makfile

3) Not to introduce any new dependency for a end user

Just my imagination: In order to keep (2) and (3), I will use Python to
build a system doing Makfile code generation. The ports framework
managers and porters just write some Python function and testing code, then
generate a proper tested and stable Makefiles for users.

-- 
Iblis Lin
林峻頤
___
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 17:46, John Marino wrote:

On 12/15/2016 10:31, Torsten Zuehlsdorff wrote:

On 15.12.2016 17:00, John Marino wrote:

It is every week.  Consider the FreeBSD forums as well.


No, it isn't. Lets check the history. This is just a general statement.
portmaster was added 2006 and the portstree startet in 1994.


Can you agree that if you combine both this list and issues that arise
on the FreeBSD forums that portmaster users talk about problems
frequently?


Yes, of course. I wasn't serious with this point and just want to 
degrade a little of the emotion to get back to a more technical and 
solvable level.



I could. My colleague did some of them. :D Even i generate some of them.


As a side discussion I would like to know what they are and if they are
valid for Synth as well.


Good question. I will ask my colleague to check; hopefully he does it also.


I see recommendations for poudriere or synth, but not for portmaster.
And i give them too.


Unfortunately portmaster get a lot of positive press on the forums.


Okay, that is just the opposite of the mailinglist. For bugzilla we have 
the helpful team around koops, which adjust the PRs. Maybe we should 
install something like that for the forum? Or just print a warning 
whenever portmaster is used (which would be much easier). We even can 
automatically link the word portmaster to an website, which gives more 
information and some warning.



Portmaster is not maintained.  Since you put your name on it, you've
made not a single commit to the repository, much less a new release. Yet
there are PRs on it.


No excuses here. You are right, but its another store. I approved a
commit which than breaks portmaster even after very good testing. And
that make me even more cautious. But also i'm not allowed to change the
code or do changes by myself, so its no surprise its very hard and i
considered to drop my maintainer line multiple times. Thats just beside
that the code is not written in a way which supports testing. So there
is a very big risk in every change. I started to rewrite it in an
private repo, but since it works (i could close many PRs) it really is
at the bottom of my list.


Interesting, but not surprising.  I know it was claimed to negate my
good point that such a piece of software needs a maintainer, but it had
to be somebody with deep level knowledge with both the capability and
*authority* to make the changes.

So now users think it's maintained and have a false confidence in it.
But with your name on it, I can't push for it to be marked "deprecated"
(with no expiration, that's important) anymore.  It's a loophole.


A breakable loophole. Since i figured out, that a complete rewrite would 
be a better solution, than the permanent danger of an very hard to test 
software, we can drop my name from it.



Please, can we somehow discourage new people from starting on it?
Anybody with a machine that doesn't have a resources to run poudriere or
synth should not be building packages on that machine.


I provide a poudriere server for my customers. Its not to nice to use,
but they can configure it like the need and without the pressure on
their own server. Maybe we need something like this to make it easier to
abandon portmaster.


For i386 and amd64 users, synth does not require more resources than
portmaster.  People on those platforms can't use "resources" as a reason
not to use Synth.  From what I can tell, portmaster people hate what
they consider unnecessary rebuilds which both poudriere and synth
(currently [1]) do, but it's this avoidance of rebuilds that cause all
their problems.

So providing them a poudriere service wouldn't solve that "problem" for
them.


It does. Since they are not aware of the "unnecessary" rebuilds, its no 
"problem" anymore.  If you have to watch rebuilding 150 ports just for 
an update of 2 ports, its a complete different story. If pkg only update 
2 ports and you can't see the work behind them, everything is fine. Its 
a little bit psychological.


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: The ports collection has some serious issues

[John Marino]

On 12/15/2016 10:31, Torsten Zuehlsdorff wrote:

On 15.12.2016 17:00, John Marino wrote:

It is every week.  Consider the FreeBSD forums as well.


No, it isn't. Lets check the history. This is just a general statement.
portmaster was added 2006 and the portstree startet in 1994.


Can you agree that if you combine both this list and issues that arise 
on the FreeBSD forums that portmaster users talk about problems 
frequently?  Does it matter if it's weekly or biweekly?  It seems to 
happen all the time on the forums, but I'm not going scan them to prove 
an exact frequency.





I could. My colleague did some of them. :D Even i generate some of them.



As a side discussion I would like to know what they are and if they are 
valid for Synth as well.



I see recommendations for poudriere or synth, but not for portmaster.
And i give them too.


Unfortunately portmaster get a lot of positive press on the forums.




Portmaster is not maintained.  Since you put your name on it, you've
made not a single commit to the repository, much less a new release. Yet
there are PRs on it.


No excuses here. You are right, but its another store. I approved a
commit which than breaks portmaster even after very good testing. And
that make me even more cautious. But also i'm not allowed to change the
code or do changes by myself, so its no surprise its very hard and i
considered to drop my maintainer line multiple times. Thats just beside
that the code is not written in a way which supports testing. So there
is a very big risk in every change. I started to rewrite it in an
private repo, but since it works (i could close many PRs) it really is
at the bottom of my list.


Interesting, but not surprising.  I know it was claimed to negate my 
good point that such a piece of software needs a maintainer, but it had 
to be somebody with deep level knowledge with both the capability and 
*authority* to make the changes.


So now users think it's maintained and have a false confidence in it. 
But with your name on it, I can't push for it to be marked "deprecated" 
(with no expiration, that's important) anymore.  It's a loophole.



Please, can we somehow discourage new people from starting on it?
Anybody with a machine that doesn't have a resources to run poudriere or
synth should not be building packages on that machine.


I provide a poudriere server for my customers. Its not to nice to use,
but they can configure it like the need and without the pressure on
their own server. Maybe we need something like this to make it easier to
abandon portmaster.


For i386 and amd64 users, synth does not require more resources than 
portmaster.  People on those platforms can't use "resources" as a reason 
not to use Synth.  From what I can tell, portmaster people hate what 
they consider unnecessary rebuilds which both poudriere and synth 
(currently [1]) do, but it's this avoidance of rebuilds that cause all 
their problems.


So providing them a poudriere service wouldn't solve that "problem" for 
them.


John

[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 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: (In)Stability of the Quarterly Branch

[Michelle Sullivan]

Vlad K. wrote:
The quarterly branch (Q) is intended to provide a set of "stable" 
packages that in the lifetime of such a branch, receive only bug and 
security fixes. That is the theory and intent behind the branch. In 
practice, however:


1. The Q branch is cut off at predetermined dates (ie. not when it's 
stable and ready), and it is cut off from HEAD, thus including the 
state of ports at that moment. This breaks the promise of stability 
and guarantees that every 3 months there will be uncertainty as to 
whether the fresh new versions are working or not. There is no such 
thing as a "Pre-Quarterly repo" which would receive all updates for 
the NEXT Q branch-off, and which would freeze and stabilize for some 
time before branch-off. And even if it did, 3 months would be too short.


It is effectively not much different from tracking HEAD and doing 
updates only every three months, with the added benefit that SOME 
security updates will come down sooner. But:


2. Unfortunately not all "security or bug-only fixes" are MFH'd, and 
as a bugzilla triager I've had the opportunity to observe this in 
practice. It can be as simple as accepting a minor upstream version 
bump, or as complex as requiring cherry-picking and backporting code 
if upstream mixes security, bug fixes with new features. It is 
none-the-less a manual work requiring ports-secteam to review and 
accept the patches. It is not clear who is supposed to do 
cherry-picked backporting if the patches to HEAD cannot be MFH'd as 
they are. It is also additional burden to the ports-secTEAM which at 
the moment is, effectively, one person.


As it is obvious that the promise of a stable repo in its current form 
requires manpower and manual work which we do not have, my proposal is 
to abandon the promise of "security/bugfix" only changes and adopt the 
approach not unlike Gentoo's, in which a "STABLE" repository receives 
ALL the updates from HEAD, but only after certain criteria has been 
met, like minimal age of changes, no open issues, a certain battery of 
regression/integration/unit tests is performed, etc...


The key, I believe, is in automation which we can achieve with this, 
and with that offer at least SOME level of stability without broken 
promises. The key to this automation is no manual review, which can 
only be achieved if we accept ALL changes, but stabilized to certain 
degree.


The idea of a "stable" repository is a valiant one, we definitely need 
it if we want to increase the usage of FreeBSD in production as more 
than just a base OS that does routing and ZFS storage -- namely 
production use of stable ports. And IMHO we only need to balance 
between how stable we can provide/guarantee it and what resources and 
manpower we have available to do so.



What are the community's thoughts on this?


That's what it needed but people charging through new versions and 
linuxifying FreeBSD screwed the pooch... This conversation/thread should 
have happened 2 years back.


Michelle
___
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 17:00, John Marino wrote:

On 12/15/2016 09:49, Torsten Zuehlsdorff wrote:

On 15.12.2016 16:29, John Marino wrote:

Although portmaster is not releated to the FreeBSD project and is an
outside tool, there aren't any alternatives from the project
itself. So
use it or die. Not a nice situation.


People have been trying to get portmaster deprecated and removed from
the
handbook but have met with resistance.


Well, yes.  Because it works, has no dependencies, and there is no
equivalent replacement.  Except maybe portupgrade, which has legacy
problems like poor default options.


Every single week, somebody falsely accuses the ports tree of being
broken but the accuser is the only one with the problem.  What do they
all have in common?  They are portmaster users.  I'll iterate, saying
"portmaster works" means applying a very generous definition of "works".


Not really, no. Its not every week and often there is a misuse or
miss-understanding of portmaster.


It is every week.  Consider the FreeBSD forums as well.


No, it isn't. Lets check the history. This is just a general statement. 
portmaster was added 2006 and the portstree startet in 1994.


Yes, there are emotions in discussions and they are really needed to 
drive things, but we need to ensure to drive in the right direction.



"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.


I'm with you at this point. portmaster is incredible complex and hard to 
understand. Therefore it is easy to misue or to misunderstand.



With an argument like this you can also state there is every week a
falsely accuse, because of poudriere. This would also be true (and is).


I couldn't state that accurately.  I can't recall any misuse reports
(and I can't come up with a feasible case in my head right now)


I could. My colleague did some of them. :D Even i generate some of them.


The recommended replacements are ports-mgmt/synth and
ports-mgmt/poudriere.
These build an entire package repository that the pkg tool can use
but they
do so in clean chrooted environments, and rebuild everything that's
required
to keep a consistent ABI. Synth is more designed for a single live
system
like a desktop or a single server, whereas poudriere is what the
freebsd
package build clusters use and is more designed for that type of
usage. Worth
taking a look.


These are package builders.  Technically preferable, given adequate
disk
space and memory, but not equivalent to portmaster.


It's like saying git and svn are not equivalent to cvs.


I have a hard time to see git in this line. Its the way you use it. Yes,
of course all three are code repositories. But one of them is a
distributed repository and the other two are not. The differences are
huge.
Of course it also depends on your usage. I personally (means "heavily
subjective) find git more than annoying. It lacks very important
features (user management), is hard to use in automatic environments and
make easy things (rename/delete branches) very hard. Other people really
like all of this. It depends.

So maybe the accusers just use the wrong tool?


The point is that you wouldn't start a new project with cvs.  You may or
may not transfer an existing project from cvs, but you're letting cvs
die by attribution.

The same should be for portmaster.  Some users will never see the light.
 Let them suffer by their own hand.  But for Pete's sake, don't
recommend it to new users.  That's not doing them any kind of service.


I see recommendations for poudriere or synth, but not for portmaster. 
And i give them too.


But both are tools which are not feasible for every situation. I often 
have a hard time to get them their space they need to make things 
better. So it would be a good idea under which circumstances portmaster 
is a good choice and whenever it is not.



Portmaster is not maintained.  Since you put your name on it, you've
made not a single commit to the repository, much less a new release. Yet
there are PRs on it.


No excuses here. You are right, but its another store. I approved a 
commit which than breaks portmaster even after very good testing. And 
that make me even more cautious. But also i'm not allowed to change the 
code or do changes by myself, so its no surprise its very hard and i 
considered to drop my maintainer line multiple times. Thats just beside 
that the code is not written in a way which supports testing. So there 
is a very big risk in every change. I started to rewrite it in an 
private repo, but since it works (i could close many PRs) it really is 
at the bottom of my list.



Please, can we somehow discourage new people from starting on it?
Anybody with a machine that doesn't have a resources to run poudriere or
synth should not be building packages on that machine.


I provide a poudriere server for my customers. Its not to nice to use, 
but they can configure it like the 

Re: The ports collection has some serious issues

[Warren Block]

On Thu, 15 Dec 2016, RW via freebsd-ports wrote:


On Thu, 15 Dec 2016 07:40:46 -0700 (MST)
Warren Block wrote:


On Thu, 8 Dec 2016, Matt Smith wrote:


On Dec 08 05:16, Daniil Berendeev wrote:


Although portmaster is not releated to the FreeBSD project and is
an outside tool, there aren't any alternatives from the project
itself. So use it or die. Not a nice situation.


People have been trying to get portmaster deprecated and removed
from the handbook but have met with resistance.


Well, yes.  Because it works, has no dependencies, and there is no
equivalent replacement.  Except maybe portupgrade, which has legacy
problems like poor default options.


That's a very minor issue, and an absurd excuse to rule-out portupgrade.


I didn't rule it out.  Portupgrade gets some of the defaults wrong, like 
not running all the 'make config' steps first.  That's a legacy issue 
because if the default changes, it could conceivably cause problems for 
existing users.  Beyond that, other than a dependency on Ruby, 
portupgrade at least exists in the same space as portmaster.

___
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

[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).

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.

Yet another layer of package validation would be very good to have, but
it isn't routine yet.

Cheers,

Matthew




signature.asc
Description: OpenPGP digital signature

Re: (In)Stability of the Quarterly Branch

[Olivier Duchateau]

On Thu, 15 Dec 2016 14:16:18 +0100
David Demelier  wrote:

> 2016-11-16 13:17 GMT+01:00 Vlad K. :
> > The quarterly branch (Q) is intended to provide a set of "stable" packages
> > that in the lifetime of such a branch, receive only bug and security fixes.
> > That is the theory and intent behind the branch. In practice, however:
> >
> > 1. The Q branch is cut off at predetermined dates (ie. not when it's stable
> > and ready), and it is cut off from HEAD, thus including the state of ports
> > at that moment. This breaks the promise of stability and guarantees that
> > every 3 months there will be uncertainty as to whether the fresh new
> > versions are working or not. There is no such thing as a "Pre-Quarterly
> > repo" which would receive all updates for the NEXT Q branch-off, and which
> > would freeze and stabilize for some time before branch-off. And even if it
> > did, 3 months would be too short.
> >
> > It is effectively not much different from tracking HEAD and doing updates
> > only every three months, with the added benefit that SOME security updates
> > will come down sooner. But:
> >
> > 2. Unfortunately not all "security or bug-only fixes" are MFH'd, and as a
> > bugzilla triager I've had the opportunity to observe this in practice. It
> > can be as simple as accepting a minor upstream version bump, or as complex
> > as requiring cherry-picking and backporting code if upstream mixes security,
> > bug fixes with new features. It is none-the-less a manual work requiring
> > ports-secteam to review and accept the patches. It is not clear who is
> > supposed to do cherry-picked backporting if the patches to HEAD cannot be
> > MFH'd as they are. It is also additional burden to the ports-secTEAM which
> > at the moment is, effectively, one person.
> >
> > As it is obvious that the promise of a stable repo in its current form
> > requires manpower and manual work which we do not have, my proposal is to
> > abandon the promise of "security/bugfix" only changes and adopt the approach
> > not unlike Gentoo's, in which a "STABLE" repository receives ALL the updates
> > from HEAD, but only after certain criteria has been met, like minimal age of
> > changes, no open issues, a certain battery of regression/integration/unit
> > tests is performed, etc...
> >
> 
> 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.

> 
> On the other hand, your idea is indeed good and could be a good start.
> Quaterly branches change too quickly. That's simple: each time I
> install a new port, I'm behind 2 or 3 quarters the last one. So I
> usually update all before installing the new one.
> 
> 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.
> 
> Waiting for more stability, I really encourage people to use poudriere
> to build packages to avoid breaking a system at each upgrade.
> 
> Regards,
> 
> -- 
> Demelier David
> ___
> 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"


-- 
olivier
___
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/15/2016 09:49, Torsten Zuehlsdorff wrote:

On 15.12.2016 16:29, John Marino wrote:

Although portmaster is not releated to the FreeBSD project and is an
outside tool, there aren't any alternatives from the project
itself. So
use it or die. Not a nice situation.


People have been trying to get portmaster deprecated and removed from
the
handbook but have met with resistance.


Well, yes.  Because it works, has no dependencies, and there is no
equivalent replacement.  Except maybe portupgrade, which has legacy
problems like poor default options.


Every single week, somebody falsely accuses the ports tree of being
broken but the accuser is the only one with the problem.  What do they
all have in common?  They are portmaster users.  I'll iterate, saying
"portmaster works" means applying a very generous definition of "works".


Not really, no. Its not every week and often there is a misuse or
miss-understanding of portmaster.


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.



With an argument like this you can also state there is every week a
falsely accuse, because of poudriere. This would also be true (and is).


I couldn't state that accurately.  I can't recall any misuse reports 
(and I can't come up with a feasible case in my head right now)






The recommended replacements are ports-mgmt/synth and
ports-mgmt/poudriere.
These build an entire package repository that the pkg tool can use
but they
do so in clean chrooted environments, and rebuild everything that's
required
to keep a consistent ABI. Synth is more designed for a single live
system
like a desktop or a single server, whereas poudriere is what the
freebsd
package build clusters use and is more designed for that type of
usage. Worth
taking a look.


These are package builders.  Technically preferable, given adequate disk
space and memory, but not equivalent to portmaster.


It's like saying git and svn are not equivalent to cvs.


I have a hard time to see git in this line. Its the way you use it. Yes,
of course all three are code repositories. But one of them is a
distributed repository and the other two are not. The differences are huge.
Of course it also depends on your usage. I personally (means "heavily
subjective) find git more than annoying. It lacks very important
features (user management), is hard to use in automatic environments and
make easy things (rename/delete branches) very hard. Other people really
like all of this. It depends.

So maybe the accusers just use the wrong tool?


The point is that you wouldn't start a new project with cvs.  You may or 
may not transfer an existing project from cvs, but you're letting cvs 
die by attribution.


The same should be for portmaster.  Some users will never see the light. 
 Let them suffer by their own hand.  But for Pete's sake, don't 
recommend it to new users.  That's not doing them any kind of service.


Portmaster is not maintained.  Since you put your name on it, you've 
made not a single commit to the repository, much less a new release. 
Yet there are PRs on it.


Please, can we somehow discourage new people from starting on it? 
Anybody with a machine that doesn't have a resources to run poudriere or 
synth should not be building packages on that machine.  Veterans have 
the option to use portmaster in a case like that, but it's not something 
that should be suggested to newbies.  Now the discussion is sidetracked, 
but really nothing has improved since I tried to get a warning added to 
portmaster months ago.


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

[RW via freebsd-ports]

On Thu, 15 Dec 2016 07:40:46 -0700 (MST)
Warren Block wrote:

> On Thu, 8 Dec 2016, Matt Smith wrote:
> 
> > On Dec 08 05:16, Daniil Berendeev wrote:  
> >> 
> >> Although portmaster is not releated to the FreeBSD project and is
> >> an outside tool, there aren't any alternatives from the project
> >> itself. So use it or die. Not a nice situation.  
> >
> > People have been trying to get portmaster deprecated and removed
> > from the handbook but have met with resistance.  
> 
> Well, yes.  Because it works, has no dependencies, and there is no 
> equivalent replacement.  Except maybe portupgrade, which has legacy 
> problems like poor default options.

That's a very minor issue, and an absurd excuse to rule-out portupgrade.
___
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 16:29, John Marino wrote:

Although portmaster is not releated to the FreeBSD project and is an
outside tool, there aren't any alternatives from the project itself. So
use it or die. Not a nice situation.


People have been trying to get portmaster deprecated and removed from
the
handbook but have met with resistance.


Well, yes.  Because it works, has no dependencies, and there is no
equivalent replacement.  Except maybe portupgrade, which has legacy
problems like poor default options.


Every single week, somebody falsely accuses the ports tree of being
broken but the accuser is the only one with the problem.  What do they
all have in common?  They are portmaster users.  I'll iterate, saying
"portmaster works" means applying a very generous definition of "works".


Not really, no. Its not every week and often there is a misuse or 
miss-understanding of portmaster.


With an argument like this you can also state there is every week a 
falsely accuse, because of poudriere. This would also be true (and is).



The recommended replacements are ports-mgmt/synth and
ports-mgmt/poudriere.
These build an entire package repository that the pkg tool can use
but they
do so in clean chrooted environments, and rebuild everything that's
required
to keep a consistent ABI. Synth is more designed for a single live
system
like a desktop or a single server, whereas poudriere is what the freebsd
package build clusters use and is more designed for that type of
usage. Worth
taking a look.


These are package builders.  Technically preferable, given adequate disk
space and memory, but not equivalent to portmaster.


It's like saying git and svn are not equivalent to cvs.


I have a hard time to see git in this line. Its the way you use it. Yes, 
of course all three are code repositories. But one of them is a 
distributed repository and the other two are not. The differences are huge.
Of course it also depends on your usage. I personally (means "heavily 
subjective) find git more than annoying. It lacks very important 
features (user management), is hard to use in automatic environments and 
make easy things (rename/delete branches) very hard. Other people really 
like all of this. It depends.


So maybe the accusers just use the wrong tool?

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"

The ports collection has some serious issues

[John Marino]

On Thu, 8 Dec 2016, Matt Smith wrote:


On Dec 08 05:16, Daniil Berendeev wrote:


Although portmaster is not releated to the FreeBSD project and is an
outside tool, there aren't any alternatives from the project itself. So
use it or die. Not a nice situation.


People have been trying to get portmaster deprecated and removed from the
handbook but have met with resistance.


Well, yes.  Because it works, has no dependencies, and there is no
equivalent replacement.  Except maybe portupgrade, which has legacy
problems like poor default options.


Every single week, somebody falsely accuses the ports tree of being 
broken but the accuser is the only one with the problem.  What do they 
all have in common?  They are portmaster users.  I'll iterate, saying 
"portmaster works" means applying a very generous definition of "works".




The recommended replacements are ports-mgmt/synth and ports-mgmt/poudriere.
These build an entire package repository that the pkg tool can use but they
do so in clean chrooted environments, and rebuild everything that's required
to keep a consistent ABI. Synth is more designed for a single live system
like a desktop or a single server, whereas poudriere is what the freebsd
package build clusters use and is more designed for that type of usage. Worth
taking a look.


These are package builders.  Technically preferable, given adequate disk
space and memory, but not equivalent to portmaster.


It's like saying git and svn are not equivalent to cvs.




It's a shame the handbook hasn't been updated to give this information.


Which information, in particular?  A section on Poudriere was submitted,
and I spent a fair amount of time editing it and getting it in there.
As far as Synth or other information, I'm not aware of any pending
Handbook or other documentation submissions.


for starters:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=214679

Previous PRs indicated that recommendations for portmaster and 
portupgrade were to be removed, but so far this PR has stalled.


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"

munin-master won't build: no 'module_name' or MANIFEST file

[Kaya Saman]

Hi,


I'm trying to rebuild munin-master but keep running into this:


cd master && /usr/local/bin/perl Build.PL
No 'module_name' was provided and it could not be inferred
from other properties.  This will prevent a packlist from
being written for this file.  Please set either 'module_name'
or 'dist_version_from' in Build.PL.
Can't find dist packages without a MANIFEST file
Run 'Build manifest' to generate one

WARNING: Possible missing or corrupt 'MANIFEST' file.
Nothing to enter for 'provides' field in metafile.
JSON::PP 2.27300 is not available
 at /usr/local/lib/perl5/site_perl/CPAN/Meta.pm line 616.
gmake[1]: *** [Makefile:435: master/Build] Error 255
gmake[1]: Leaving directory 
'/usr/ports/sysutils/munin-master/work/munin-2.0.27'

*** Error code 1

Stop.
make: stopped in /usr/ports/sysutils/munin-master


What can I do to fix it? It asks to run: Build manifest - but where do I 
run this?



Many thanks.


Kaya

___
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

[Warren Block]

On Thu, 8 Dec 2016, Matt Smith wrote:


On Dec 08 05:16, Daniil Berendeev wrote:


Although portmaster is not releated to the FreeBSD project and is an
outside tool, there aren't any alternatives from the project itself. So
use it or die. Not a nice situation.


People have been trying to get portmaster deprecated and removed from the 
handbook but have met with resistance.


Well, yes.  Because it works, has no dependencies, and there is no 
equivalent replacement.  Except maybe portupgrade, which has legacy 
problems like poor default options.


The recommended replacements are ports-mgmt/synth and ports-mgmt/poudriere. 
These build an entire package repository that the pkg tool can use but they 
do so in clean chrooted environments, and rebuild everything that's required 
to keep a consistent ABI. Synth is more designed for a single live system 
like a desktop or a single server, whereas poudriere is what the freebsd 
package build clusters use and is more designed for that type of usage. Worth 
taking a look.


These are package builders.  Technically preferable, given adequate disk 
space and memory, but not equivalent to portmaster.



It's a shame the handbook hasn't been updated to give this information.


Which information, in particular?  A section on Poudriere was submitted, 
and I spent a fair amount of time editing it and getting it in there.
As far as Synth or other information, I'm not aware of any pending 
Handbook or other documentation submissions.

___
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

[Warren Block]

On Thu, 8 Dec 2016, Daniil Berendeev wrote:


5) svn repository.
I don't want to spark a holy war and I don't belong to those type of
people who are always obsessed that something isn't done in their way.
But guys, svn is not a good tool for ports. Just for one reason,
actually (as for me, I could tolerate anything else, but not this one)
-- size. The size of repository is 20G+ and growing. I don't want to
pull 20G+ in /usr/ports just because I need to use ports. It's just
sick. The repository is so big because, as all ya know, svn is expensive
in branch operations. Since you've began to do those 2xxxQx branches the
size of the repository began to grow rapidly. It's inefficient and
uncomfortable. For such a work something like git or mercurial should be
used, they'd fit in 3-4G.


Here, it doesn't look like that. Don't forget that /usr/ports/distfiles 
accumulates old versions and must be manually cleaned out from time to 
time.  portmaster has a couple of options to remove distfiles that are 
not needed.


% du -hd0 /usr/ports
8.1G/usr/ports
% du -hd0 /usr/ports/distfiles
6.5G/usr/ports/distfiles

After copying that to /tmp and deleting distfiles entirely:

% du -hd0 /tmp/usr/ports
1.4G/tmp/usr/ports

Deleting /usr/ports/distfiles entirely is something I avoid because it 
seems that just when an urgent rebuild is needed, a distfile will be 
unfetchable. The portmaster options can keep distfiles only for 
currently installed ports, or current distfiles for any port, whether 
installed or not.

___
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

[Miroslav Lachman]

Torsten Zuehlsdorff wrote on 2016/12/15 14:43:


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.


www/redmine is a special case like for example GitLab. This are ports
based on rubygems and the ports-tree has a hard time to replicate the
gems. When one port need an update for a specific gem another can break.

Other systems avoid the problem by ignoring it. You need to install and
maintain all gems by yourself. This includes updates, security checks
and of course installation of dependencies.


First - I really appreciate your work on ports!

And now Redmine - I think I was bitten by every Redmine failure after 
upgrade :)


I wonder if the solution for ports like Redmine can be some kind of 
isolation. Python have virtualenv, AFAIK Ruby has something like this 
too. Will it be possible to connect ports (packages) with some type of 
"environment" defined just for "this package"?


Miroslav Lachmanh
___
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 15.12.2016 14:16, David Demelier wrote:

2016-11-16 13:17 GMT+01:00 Vlad K. :

The quarterly branch (Q) is intended to provide a set of "stable" packages
that in the lifetime of such a branch, receive only bug and security fixes.
That is the theory and intent behind the branch. In practice, however:

1. The Q branch is cut off at predetermined dates (ie. not when it's stable
and ready), and it is cut off from HEAD, thus including the state of ports
at that moment. This breaks the promise of stability and guarantees that
every 3 months there will be uncertainty as to whether the fresh new
versions are working or not. There is no such thing as a "Pre-Quarterly
repo" which would receive all updates for the NEXT Q branch-off, and which
would freeze and stabilize for some time before branch-off. And even if it
did, 3 months would be too short.

It is effectively not much different from tracking HEAD and doing updates
only every three months, with the added benefit that SOME security updates
will come down sooner. But:

2. Unfortunately not all "security or bug-only fixes" are MFH'd, and as a
bugzilla triager I've had the opportunity to observe this in practice. It
can be as simple as accepting a minor upstream version bump, or as complex
as requiring cherry-picking and backporting code if upstream mixes security,
bug fixes with new features. It is none-the-less a manual work requiring
ports-secteam to review and accept the patches. It is not clear who is
supposed to do cherry-picked backporting if the patches to HEAD cannot be
MFH'd as they are. It is also additional burden to the ports-secTEAM which
at the moment is, effectively, one person.

As it is obvious that the promise of a stable repo in its current form
requires manpower and manual work which we do not have, my proposal is to
abandon the promise of "security/bugfix" only changes and adopt the approach
not unlike Gentoo's, in which a "STABLE" repository receives ALL the updates
from HEAD, but only after certain criteria has been met, like minimal age of
changes, no open issues, a certain battery of regression/integration/unit
tests is performed, etc...


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.


www/redmine is a special case like for example GitLab. This are ports 
based on rubygems and the ports-tree has a hard time to replicate the 
gems. When one port need an update for a specific gem another can break.


Other systems avoid the problem by ignoring it. You need to install and 
maintain all gems by yourself. This includes updates, security checks 
and of course installation of dependencies.



On the other hand, your idea is indeed good and could be a good start.
Quaterly branches change too quickly. That's simple: each time I
install a new port, I'm behind 2 or 3 quarters the last one. So I
usually update all before installing the new one.

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.


Yes, there are problems and tests are very helpful. But you need to 
check why something is broken. Often the upstream is broken, not the 
port. In the case of redmine the ports-tree lacks the pessimistic 
operator which can catch many of the breaks in the last. It is one idea 
to teach the ports-tree how this work. Also there is an ongoing effort 
in increasing the tests. Every help is appreciated!



Waiting for more stability, I really encourage people to use poudriere
to build packages to avoid breaking a system at each upgrade.


This is a good idea. But does not help everytime. Many rubygem based 
ports build just fine, but fail afterwards.


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

[David Demelier]

2016-11-16 13:17 GMT+01:00 Vlad K. :
> The quarterly branch (Q) is intended to provide a set of "stable" packages
> that in the lifetime of such a branch, receive only bug and security fixes.
> That is the theory and intent behind the branch. In practice, however:
>
> 1. The Q branch is cut off at predetermined dates (ie. not when it's stable
> and ready), and it is cut off from HEAD, thus including the state of ports
> at that moment. This breaks the promise of stability and guarantees that
> every 3 months there will be uncertainty as to whether the fresh new
> versions are working or not. There is no such thing as a "Pre-Quarterly
> repo" which would receive all updates for the NEXT Q branch-off, and which
> would freeze and stabilize for some time before branch-off. And even if it
> did, 3 months would be too short.
>
> It is effectively not much different from tracking HEAD and doing updates
> only every three months, with the added benefit that SOME security updates
> will come down sooner. But:
>
> 2. Unfortunately not all "security or bug-only fixes" are MFH'd, and as a
> bugzilla triager I've had the opportunity to observe this in practice. It
> can be as simple as accepting a minor upstream version bump, or as complex
> as requiring cherry-picking and backporting code if upstream mixes security,
> bug fixes with new features. It is none-the-less a manual work requiring
> ports-secteam to review and accept the patches. It is not clear who is
> supposed to do cherry-picked backporting if the patches to HEAD cannot be
> MFH'd as they are. It is also additional burden to the ports-secTEAM which
> at the moment is, effectively, one person.
>
> As it is obvious that the promise of a stable repo in its current form
> requires manpower and manual work which we do not have, my proposal is to
> abandon the promise of "security/bugfix" only changes and adopt the approach
> not unlike Gentoo's, in which a "STABLE" repository receives ALL the updates
> from HEAD, but only after certain criteria has been met, like minimal age of
> changes, no open issues, a certain battery of regression/integration/unit
> tests is performed, etc...
>

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.

On the other hand, your idea is indeed good and could be a good start.
Quaterly branches change too quickly. That's simple: each time I
install a new port, I'm behind 2 or 3 quarters the last one. So I
usually update all before installing the new one.

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.

Waiting for more stability, I really encourage people to use poudriere
to build packages to avoid breaking a system at each upgrade.

Regards,

-- 
Demelier David
___
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"

Make index fails with no entry for /usr/ports/audio/linux-c7-mikmod

[Mike Clarke]

curlew:/root# freebsd-version -ku
11.0-RELEASE-p2
11.0-RELEASE-p5
curlew:/root# make -C /usr/ports index
Generating INDEX-11 - please wait..--- describe.accessibility ---
--- describe.arabic ---
--- describe.archivers ---

[snip]

--- describe.x11-toolkits ---
--- describe.x11-wm ---
make_index: /usr/ports/games/linux-uplink-demo: no entry for 
/usr/ports/audio/linux-c7-mikmod

curlew:/root# ls -l /usr/ports/audio/linux-c7-mikmod
ls: /usr/ports/audio/linux-c7-mikmod: No such file or directory

https://www.freebsd.org/cgi/ports.cgi?query=linux-c7-mikmod=all reports 
nothing found so what's causing make index to try to index it?

-- 
Mike Clarke
___
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 you maintain which are out of date

[portscout]

Dear port maintainer,

The portscout new distfile checker has detected that one or more of your
ports appears to be out of date. Please take the opportunity to check
each of the ports listed below, and if possible and appropriate,
submit/commit an update. If any ports have already been updated, you can
safely ignore the entry.

You will not be e-mailed again for any of the port/version combinations
below.

Full details can be found at the following URL:
http://portscout.freebsd.org/po...@freebsd.org.html


Port| Current version | New version
+-+
devel/libthai   | 0.1.25  | 0.1.26
+-+
math/giacxcas   | 1.2.2-57| 1.2.2-105
+-+
net/ipsumdump   | 1.85| 1.86
+-+


If any of the above results are invalid, please check the following page
for details on how to improve portscout's detection and selection of
distfiles on a per-port basis:

http://portscout.freebsd.org/info/portscout-portconfig.txt

Thanks.
___
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: No port should need root for make fetch

[Mathieu Arnold]

Le 14/12/2016 à 06:17, Peter Jeremy a écrit :
> On 2016-Dec-13 21:32:36 +0100, "Julian H. Stacey"  wrote:
>> IMO No port should need root for 
>>  cd /usr/ports; make -i fetch
> In a stock FreeBSD install, all ports require root to both fetch and build.
> You have customised your system in a non-standard way so you are getting
> non-standard behaviour which doesn't match you expectations.

That is plain not true. The numbers of ports that need root to fetch and
build can be counted on one hand, and need to be fixed. We have QAT
builds that check it:
http://package19.nyi.freebsd.org/build.html?mastername=103i386-default-build-as-user=428533

poudriere-devel defaults as doing everything as a non root user (default
nobody), except executing all the -depends target, as they need to
install stuff in LOCALBASE.


-- 
Mathieu Arnold




signature.asc
Description: OpenPGP digital signature