Re: Removing documentation

[Miroslav Lachman]

Kevin Oberman wrote on 02/16/2016 20:44:

[...]


I already see the looming battle over a future
replacement of the init system with something both more functional and
manageable. I think systemd went way too heavily toward "functional" and
ignored the manageable side. I hope FreeBSD does better, especially in
avoiding over-reach.

I see much that I like (and a fair bit I don't) in launchd, for example and
I really need to keep a better eye on what NextBSD is doing. It is
certainly interesting and has some really good people working on it.


I see "nosh" as really interesting replacement of init and rc.d

https://www.freebsd.org/news/status/report-2015-10-2015-12.html#The-nosh-Project

http://homepage.ntlworld.com./jonathan.deboynepollard/Softwares/nosh.html

It seems straight forward and I hope I will have time to test it soon.

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: Removing documentation

[Kevin Oberman]

On Tue, Feb 16, 2016 at 7:57 AM,  wrote:

> On Mon, Feb 15, 2016 at 06:14:02PM +0100, John Marino wrote:
> > And now the fully circle.  This is FreeBSD's Godwin's law.  You know the
> > discussion is over when somebody says that "[issue] of the day" is the
> > root cause of BSD being eclipsed by Linux.  Since I've heard [issue]
> > replaced about 200 times, I'm kind of doubting it.  I guess it's purpose
> > is to make everyone involved with "[issue]" to feel personally
> > responsible and oh what could have been if you hadn't of made the wrong
> > decision
>
> I was under the impression that what really hurt BSD vs Linux was the
> AT vs UCB lawsuit. If that lawsuit hadn't happened Linus would not have
> created Linux. He's said so himself.
> --
> Kevin P. Nealhttp://www.pobox.com/~kpn/
>

Yes, the license uncertainty of the period is why Linux exists and why it
gained immediate popularity. Inertia can be a wonderful thing.

But that was then and this is now and the popularity of Linux vs. BSD and
of various distributions of them is driven by many factors. Linux has FAR
more developers and has long been able to have support for newer devices
much more quickly than BSD. This has, in turn, fed the growth of Linux.

OTOH, BSD had become rather popular in the embedded systems space. Its
license and strong support for servers and embedded systems has helped. I
think systemd has been a big mistake for Linux and is moving many people to
BSD, even those who had not previously used it. In recent years the distros
seem to be intent on behaving like Windows. I look at the directions of
e.g. Gnome and, to a lesser extent KDE as the result of devs who grew up
with Windows as trying to make their environment more "Windows like". This
is combined with a philosophy that allowing and even encouraging a wide
variety of configuration changes as has traditionally been the norm for all
UNIX-type systems was frightening off too many people.

It is a combination of these and other factors that control the ebb and
flow of OS and distro popularity. I think trying to be popular is best
served by maximizing functionality and usability in general and for
specific purposes. In general, I think FreeBSD is doing a pretty good job
ATM and, while I don't always agree with everything, I think I'll probably
continue using it as my OS of choice. I'll also continue to speak up when I
disagree with the direction. I already see the looming battle over a future
replacement of the init system with something both more functional and
manageable. I think systemd went way too heavily toward "functional" and
ignored the manageable side. I hope FreeBSD does better, especially in
avoiding over-reach.

I see much that I like (and a fair bit I don't) in launchd, for example and
I really need to keep a better eye on what NextBSD is doing. It is
certainly interesting and has some really good people working on it.
--
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: Removing documentation

[Michelle Sullivan]

Jim Ohlstein wrote:
> Hello,
>
> On 2/15/16 3:40 PM, Michelle Sullivan wrote:
>> John Marino wrote:
>>> On 2/15/2016 6:32 PM, Roger Marquis wrote:
>>>
> This makes no sense.  Ports are not tied to base releases.
> And you think lack of developer resources is an invalid reason?
>
 There was no mid-release issue with base as far as I know.  The
 issue was
 with ports and by extension pkgng (and related -ngs).

>>>
>>> ports are developed independently.  They do not follow release
>>> schedules.  Ports have to support all supported releases, that's the
>>> only connection.
>>>
>> Yeah, I'd agree with this... except...
>>
>> pkg_* tools don't exist on 10.x only pkgng...  that makes it base os
>> thing.. even if it's downloaded in/via ports..
>>
>> So sorry don't claim it's only part of the ports system, because whilst
>> it maybe built and administered there, the tools it replaced were
>> removed from the base OS at the very beginning of 10.x...
>
> This is like milking a dead cow here. Even if you get something out of
> it you're not going to drink it.

One of the reasons that over the last few months I have been ignoring
most threads on here and IRC... just looking for something I need to
know about only.
>
> If you want to be using a 2014 OS in 2022, then a RHEL derived system
> is the product for you. Enjoy it. I don't believe that there is an
> upgrade path in RHEL, so you'll either have to retire hardware or nuke
> your systems to upgrade.

I don't, I'm forced to now.

>
> No one forced you to use 10.x before you were ready. 9 is still
> supported to this day. And as has been pointed out, pkg_ tools were in
> ports should you have wanted to continue to use them, and you could
> have kept them and frozen your ports tree, as has been pointed out.
I don't have a 10.x box.  I do still have 40+ 9.x boxes and a non-frozen
ports tree where i have backported many of the new changes to the old
pkg_* system ... just because in the immortal words "these changes
cannot work with pkg_* tools, we needed to change everything to move
forward." (or something very close to those words.)

>
> Could the pkg(8) roll out have been handled better? Yes!


> Red Hat, which is now your preferred product, 
No, it's the product I have to use because that is now company policy.

> is a for-profit company with over 8000 paid employees, many of whom
> are testing and testing and testing. They never update anything except
> at the point of a gun, and then only after extensive testing. On the
> plus side, it's stable. It never really changes. FreeBSD, on the other
> hand, is a comparatively small organization and an operating system
> that moves forward, though sometimes it's two steps forward and one
> back.. Some things need to be tested in the field to find out where
> and what needs to be changed/fixed/improved. That's the way it is. Was
> this an epic fail? That's a matter of opinion, though we all already
> know yours. The fact is that you had choices. You made those choices
> with your eyes open (if you didn't then shame on you!) 

I have very little choice because whilst my eyes were open, I missed one
message ... *ONE* message that said (paraphrasing), "as of the EOL date
the old tools will be broken"


> and things didn't go as smoothly as you'd have liked. As I said, it's
> time to move on. Your arguments are specious.
>
>
Your assumptions about me and my motives are very specious.  I have
already moved on professionally (as in, in my job) and I replied to this
thread only to let the original poster know there were not alone in
their thoughts or arguments.  Others, you included have persisted in
telling me how and why I'm wrong without realising that if I amd wrong
so are you, just as if I am right so are you because I am talking about
my experience, observations and opinion, which are mine and mine alone,
you will keep the argument going whilst ever you deny my observations
and opinions.

-- 
Michelle Sullivan
http://www.mhix.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: Removing documentation

[Baho Utot]

Michelle Sullivan wrote:

John Marino wrote:

On 2/15/2016 5:59 PM, Roger Marquis wrote:
   

It was actually worse than that.  Those of us who questioned the wisdom
of such disruptive and backwards-incompatible changes being implemented
mid-release instead of at a release boundry were A) ignored, B) told that
there were not enough (developer) resources, and C) even the announcement
was unprofessional and lacked justification for the rush job:
 

This makes no sense.  Ports are not tied to base releases.
And you think lack of developer resources is an invalid reason?
   

Actually it made perfect sense... (for a change) ... make pkgng the
default on 10.x and allow people to use either on 8.4 and 9.x ...  this
made perfect sense...  Make base packaging using similar/same tools as
part of 11+ makes perfect sense...


No, though... arbitrary date set, f**k real users, f**k whether it
works or not, because we need people to put it in production so we can
test our buggy software...

   

   There comes a time in the life cycle of just about every software
   package that it has bee re-evaluated, refreshed, deprecated or just
   retired.

   It is time that we bid farewell to the old pkg_* software that has been
   part of FreeBSD since the beginning, and has served us well.  After
   years of development, testing, and playing, pkg(8) has become a
   suitable replacement.

"there comes a time"?  "time that we bid farewell"?  These are not
suitable criteria IMO for dropping support of mission-critical
subsystems.  The FreeBSD Foundation SHOULD have played a part in insuring
a smoother transition to pkgng (much less portsng and, gack, rcng) but
this doesn't seem to have been on their radar.
 

You know good and well that people kick the can down the road FOREVER.
You could have announced it 3 years ahead and people would still scream
NOT YET!  NOT YET!  This would NEVER happen in Linux!

It doesn't matter where you draw the line, you will never get everyone
to respect it.  It's never enough time.
   

Line drawn - at the next major version...  that's an easy win... people
can complain, but they can't argue that it isn't a good decision because
they can choose... upgrade/don't upgrade... we didn't get the chance to
choose ... it was forced down peoples necks... working or not.
Fortunately I was able to get the old system working again... and in
fact keep it up to date until about 3 months ago... (and only stopped
there because I have other things to do - will go back to it again later.)


 From my perspective as an advocate and long-time user (since 2.0.5) this
   

marked a low-point in the viability of FreeBSD vis-a-vis other FOSS
distributions.  Thankfully, going forward from FreeBSD 11 the release
cycle has been lengthened and base is going to be packaged.  Those of use
who support large numbers of dev and production systems can at least
expect that future upgrades won't be as time-consuming or, hopefully, as
buggy.
 

"large numbers of dev and production systems" (push to memory stack)



   

I believe this is factually incorrect.  We were aware but the decisions
were being made by core developers who were not, apparently, interested
in our concerns or the expected fallout.
 

So you chose to ignore the deadlines in the hopes the pleading would
work?  You intentionally did not prepare against the published timetable?
   

Well I didn't know - despite following the conversations on the public
lists - until 3 weeks before the event that the change was going to
deliberately and irrevocably break the old systems... again...

   

There was always the option of freezing the tree and pulling in the
security updates manually until you were ready to migrate to pkg(8) too.
   

Sure, if you can afford to pay a full-time core dev there's the option of
backporting but even this was made impractical by the simultaneous
deprecation of the pre-ng ports tree, make version and pkg format.
 

No, it's not fully time.  You just said "large numbers of dev and
production systems", so I am pretty confident the business case would
have been there for this.

It's a business, right?  You aren't talking about a shoestring hobby.
   

Dunno about Roger, but I am and I had been campaigning internally about
getting support for FreeBSD as a platform and support for the foundation
in the way of devs and/or cash...  that is *never* going to happen now.
Money has been allocated and sent to Redhat (nothing to do with me, but
the pkgng debacle left me without legs to argue the case, so the
decision makers stuffed that.)


There are lots of reasons why Linux has effectively eclipsed BSD
including device drivers, unattended deployments and install menus but
8.X's wholesale throwing of so many of us under the bus was by far the
worst.
 

And now the fully circle.  This is FreeBSD's Godwin's law.  You know the
discussion is over when somebody says that "[issue] of the day" is the
root cause of BSD being 

Re: Removing documentation

[Michelle Sullivan]

John Marino wrote:
> On 2/15/2016 9:40 PM, Michelle Sullivan wrote:
>   
>> Yeah, I'd agree with this... except...
>>
>> pkg_* tools don't exist on 10.x only pkgng...  that makes it base os
>> thing.. even if it's downloaded in/via ports..
>>
>> So sorry don't claim it's only part of the ports system, because whilst
>> it maybe built and administered there, the tools it replaced were
>> removed from the base OS at the very beginning of 10.x...
>> 
>
> What stopped you from installing pkg_* tools from the ports tree on
> 10.x? 
Which port, I wasn't even aware the pkg_* tools where there?  Not
forgetting they wouldn't actually work because the ports tree actively
installs and uses pkg (no matter what options you have) so you're
screwed regardless.

>  You're just talking about them being removed from base, but you
> weren't prohibited from using the tools until they were removed from the
> ports tree (and then you could have just frozen the tree while they were
> still present)
>   
Nice idea except there were a slew of vulnerabilities (notable openssl
IIRC) which had to be patched... and IIRC it wasn't even back ported to
the quarterly.. I know I asked for several patches to be put into the
quarterly and they never were (and one of those patches was on a port I
maintained.)

> Plus now you're in a weird place where you can freely migrate to the
> latest release (10.x) but can't freely migrate package tools?
>   
Sorry? 

pre 8.4 pkg_* only.
8.4 + 9.x pkg_* or pkgng - user choice.
10.x pkgng only.

Seems to be a good path to get people to switch without the pain.

> Michelle, it's seriously very weak to say ports are tied to releases
> because something moved out of base.  Stuff moves out of base all the
> time (and actually not fast enough).
>   
Wasn't the point I was making, but people will jump on that to give
weight to their argument.  I was supporting someone else's notion that
it would have been a lot more sensible and painless had it been done ...
(eg like I suggested above) ... however it wasn't.. arbitrary date
set...  That said, you cannot deny..  10.x didn't have working pkg_*
tools (as in usable - because bapt (and others) made sure there were so
many version checks so if you were on 10.x the ports tree would not use
pkg_* tools even if you went to the source and compiled them like I
did...  seems to me like they had already chosen to go the way I
suggested above, but too many people stayed clear of 10.0 so they forced
the issue on everyone else...  Here's the fact: I run configure and my
systems, not some random wheeny that wants me to debug their software. 
I know the 'wheeny' is friends with people on here.. and a lot more
respected by many than I ever will be when it comes to this mailing
list, but I really don't care, I say it how it is, you may agree or
disagree with me, I will respect you if you do, however you will never
change my mind nor will I just shut up and go away whilst I have a
single box affected (which means until they are all migrated.)

Michelle

-- 
Michelle Sullivan
http://www.mhix.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: Removing documentation

[Jim Ohlstein]

Hello,

On 2/15/16 3:40 PM, Michelle Sullivan wrote:

John Marino wrote:

On 2/15/2016 6:32 PM, Roger Marquis wrote:


This makes no sense.  Ports are not tied to base releases.
And you think lack of developer resources is an invalid reason?


There was no mid-release issue with base as far as I know.  The issue was
with ports and by extension pkgng (and related -ngs).



ports are developed independently.  They do not follow release
schedules.  Ports have to support all supported releases, that's the
only connection.


Yeah, I'd agree with this... except...

pkg_* tools don't exist on 10.x only pkgng...  that makes it base os
thing.. even if it's downloaded in/via ports..

So sorry don't claim it's only part of the ports system, because whilst
it maybe built and administered there, the tools it replaced were
removed from the base OS at the very beginning of 10.x...


This is like milking a dead cow here. Even if you get something out of 
it you're not going to drink it.


If you want to be using a 2014 OS in 2022, then a RHEL derived system is 
the product for you. Enjoy it. I don't believe that there is an upgrade 
path in RHEL, so you'll either have to retire hardware or nuke your 
systems to upgrade.


No one forced you to use 10.x before you were ready. 9 is still 
supported to this day. And as has been pointed out, pkg_ tools were in 
ports should you have wanted to continue to use them, and you could have 
kept them and frozen your ports tree, as has been pointed out.


Could the pkg(8) roll out have been handled better? Yes! Hey, I'm not 
happy about Bush v Gore in 2000 but I'm not still crying about it. 
You're frustrated, angry, bitter, whatever. I'm terribly sorry but it's 
ime to move on.


Red Hat, which is now your preferred product, is a for-profit company 
with over 8000 paid employees, many of whom are testing and testing and 
testing. They never update anything except at the point of a gun, and 
then only after extensive testing. On the plus side, it's stable. It 
never really changes. FreeBSD, on the other hand, is a comparatively 
small organization and an operating system that moves forward, though 
sometimes it's two steps forward and one back.. Some things need to be 
tested in the field to find out where and what needs to be 
changed/fixed/improved. That's the way it is. Was this an epic fail? 
That's a matter of opinion, though we all already know yours. The fact 
is that you had choices. You made those choices with your eyes open (if 
you didn't then shame on you!) and things didn't go as smoothly as you'd 
have liked. As I said, it's time to move on. Your arguments are specious.



--
Jim Ohlstein


"Never argue with a fool, onlookers may not be able to tell the 
difference." - Mark Twain

___
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: Removing documentation

[Jeffrey Bouquet via freebsd-ports]

On 02/15/2016 09:32, Roger Marquis wrote:
>> This makes no sense.  Ports are not tied to base releases.
>> And you think lack of developer resources is an invalid reason?
>
> There was no mid-release issue with base as far as I know.  The issue was
> with ports and by extension pkgng (and related -ngs).
>
>> You know good and well that people kick the can down the road FOREVER.
>> You could have announced it 3 years ahead and people would still scream
>> NOT YET!  NOT YET!  This would NEVER happen in Linux!
>
> The announcement
> 
>
> was dated Feb 3 2014, leaving all of 7 months until the planned
> deprecation.  Even if you could make a case that pkgng was ready (it
> wasn't) 7 months is far less than the 2 calendar year and dozens of
> person-year cycles required by some infrastructure-critical production
> environments.  It's even farther from the 7+ years that other FOSS
> distributions support their releases.

> 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"
IIRC pkg(ng) was why I joined the freebsd-current mailing list, arguing
there several times against
its abstraction from command-line pipe tricks on the /var/db/pkg
subfiles... by portmaster etc...
[ if not, it was the second issue posted about... ]


Since upgraded all systems (almost all) to pkg. (Not without breakage,
sorry to say, but did one or two
reinstalls of the OS, thankfully not on often-used systems...)

And have  a near-seamless twice-weekly upgrade.
...
However, I would surmise it best to eventually (as I stated before)
re-enable the pkg_tools as  a
parallel subsystem ( sort of like a shadow fallback /var/db/pkg if one's
sqlite3 file goes missing...)
(or an urgent-upgrade path with portmaster -d -B -P -i -g (or something
if the usual one is broken..)
Or even a 'pkg runs in a sandbox 'pkg upgrade' AND portmaster -d -B -P
-i -g and actually does the
upgrade that completes without error... maybe examinable by the user

However, that is all just a subset of the wish list here (like reverse
engineering the MOVED portmanager
and making it pkg-capable... )

 And some schemes I postulate here may be more doable on paper than
in practice...

BTW made synth ccache-aware and ran it for the first time 'en masse'
today.  Unclear whether it with
the build-only command, did actual installs or not, (some were listed as
FAILED) but it sure was
*pretty* ...  (red, green...) to see.

Apologies for treading off-topic.
___
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: Removing documentation

[John Marino]

On 2/15/2016 9:40 PM, Michelle Sullivan wrote:
> Yeah, I'd agree with this... except...
> 
> pkg_* tools don't exist on 10.x only pkgng...  that makes it base os
> thing.. even if it's downloaded in/via ports..
> 
> So sorry don't claim it's only part of the ports system, because whilst
> it maybe built and administered there, the tools it replaced were
> removed from the base OS at the very beginning of 10.x...

What stopped you from installing pkg_* tools from the ports tree on
10.x?  You're just talking about them being removed from base, but you
weren't prohibited from using the tools until they were removed from the
ports tree (and then you could have just frozen the tree while they were
still present)

Plus now you're in a weird place where you can freely migrate to the
latest release (10.x) but can't freely migrate package tools?

Michelle, it's seriously very weak to say ports are tied to releases
because something moved out of base.  Stuff moves out of base all the
time (and actually not fast enough).

JOhn
___
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: Removing documentation

[Michelle Sullivan]

John Marino wrote:
> On 2/15/2016 6:32 PM, Roger Marquis wrote:
>   
>>> This makes no sense.  Ports are not tied to base releases.
>>> And you think lack of developer resources is an invalid reason?
>>>   
>> There was no mid-release issue with base as far as I know.  The issue was
>> with ports and by extension pkgng (and related -ngs).
>> 
>
> ports are developed independently.  They do not follow release
> schedules.  Ports have to support all supported releases, that's the
> only connection.
>   
Yeah, I'd agree with this... except...

pkg_* tools don't exist on 10.x only pkgng...  that makes it base os
thing.. even if it's downloaded in/via ports..

So sorry don't claim it's only part of the ports system, because whilst
it maybe built and administered there, the tools it replaced were
removed from the base OS at the very beginning of 10.x...

Michelle

-- 
Michelle Sullivan
http://www.mhix.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: Removing documentation

[Roger Marquis]

I've never met bapt, who implemented pkg, or bdrewery, but from
what I can see, implementing pkg was not a short-term project for them.


Short-term perspective != short-term project considering they're both
relative to the ecosystem.


It was the only way out from the technical burden of the old scheme,
they saw the problem, and went to solve it.


Perhaps we're not talking about the same thing here.  Most of us fully
support pkgng, it's devs and goals.  We can't say this loud enough:
Thanks Baptist!  Thanks Brian!  Thanks everyone who contributed!  This
is, however, tangental from discussions of how to implement change
control for the greatest good and least pain.  Such project management is
critical IMO for the future viability of FreeBSD, its end-users and
businesses that use it.


From another perspective it is a bit of a chicken and egg issue

considering that devs by nature, myself included, enjoy new features and
new code more than fixing bugs or long-term planning.  Bugs aside I think
we all would much rather be writing code or tweaking systems used by 100s
of thousands rather than simply thousands.  The point I'm trying to make
is:

 A) a larger FreeBSD end-users is worth the effort, and

 B) the way to get there, IMO, is with fewer upgrade hassles and better
 end-user APIs

MO perhaps but based on real world decisions at real world companies.


And it's a bit strange to disparage such a person with a snide remark
like 'short-term perspective'. It's always easy to argue from the
sideline.


Definetly not on the sideline having spent the better part of 30 years
years working with Unix and 21 with FreeBSD.  For the sake of open
discussion regarding substantive issues, however, I beg you take back or
better substantiate such grossly unfair and inaccurate characterizations.

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: Removing documentation

[Roger Marquis]

Ports have to support all supported releases, that's the only connection.


They have historically and for good reason.  Cross-platform ports are
FreeBSD's strongest feature, but it would not have taken a tremendous
amount of effort to have supported both pre- and post- ng trees in tandem
for say a year.


what FOSS distributions support releases for 7+ years for gratis?  One
pays for that kind of support.  Did your organization offer to pay for
extended support?


We would have loved to if that option had been available.  The cost would
have been minuscule compared to doing the same with contractors and
in-house devs.  Now that Xinuos is around we at least have that option.


All your colleagues, developers, administrators, and managers want
enterprise level support without paying any money at all?   They *all*
think volunteers provide that level of support just because?


Please don't make so many assumptions.  No BSD shop that I know of needs
enterprise level support.  Had that with Sun (SunSove) but they never had
ports much less a good security track record.  All we need is to be able
to compile ports and  patch the few kernel security issues that come up.
It's not something beyond the abilities of our community (IMO) but rather
more of a policy issue.

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: Removing documentation

[Kurt Jaeger]

Hi!

> > So, if it was too burdensome for the whole project to support
> > two trees (that probably was the estimate for the core developers
> > involved [and I'm not one of them]), why, do you think, would
> > it have worked for a sub-fraction of the project ?
> 
> Thanks Kurt, for cutting to the core issue.  It's one that has dogged
> FreeBSD for some time now i.e., to either A) manage change-control with a
> long term perspective with the goal of growing or at least retaining the
> installed base of end-users or B) with a short-term perspective for the
> benefit of our generous and skilled developers.

I've never met bapt, who implemented pkg, or bdrewery, but from
what I can see, implementing pkg was not a short-term project for them.

It was the only way out from the technical burden of the old scheme,
they saw the problem, and went to solve it.

If someone A wants someone B else to work harder for his own benefit:
You can always hope that B is doing it, but you can not expect it.

And it's a bit strange to disparage such a person with a snide remark
like 'short-term perspective'. It's always easy to argue from the
sideline.

-- 
p...@opsec.eu+49 171 3101372 4 years to go !
___
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: Removing documentation

[dr . klepp]

Am Montag, 15. Februar 2016 schrieb Roger Marquis:
> There are lots of reasons why Linux has effectively eclipsed BSD
> including device drivers, unattended deployments and install menus but
> 8.X's wholesale throwing of so many of us under the bus was by far the
> worst.

Well, have you experience with "systemd"? That's the Linux nemesis that drives 
people to *BSD - including me.

Nik


-- 
Please do not email me anything that you are not comfortable also sharing with 
the NSA.
___
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: Removing documentation

[John Marino]

On 2/15/2016 6:31 PM, Michelle Sullivan wrote:
> Actually it made perfect sense... (for a change) ... make pkgng the
> default on 10.x and allow people to use either on 8.4 and 9.x ...  this
> made perfect sense...  Make base packaging using similar/same tools as
> part of 11+ makes perfect sense... 

It might make sense if you had zero knowledge of how ports are developed
and made the assumption they are synchronized to three base branches.
They aren't.

One ports tree, developed independently.


> No, though... arbitrary date set, f**k real users, f**k whether it
> works or not, because we need people to put it in production so we can
> test our buggy software...

Even with asterisks, I'm not happy with swear words like this on a mail
list.  Can we keep it cleaner?


> Line drawn - at the next major version...  that's an easy win... people
> can complain, but they can't argue that it isn't a good decision because
> they can choose... upgrade/don't upgrade... we didn't get the chance to
> choose ... it was forced down peoples necks... working or not. 
> Fortunately I was able to get the old system working again... and in
> fact keep it up to date until about 3 months ago... (and only stopped
> there because I have other things to do - will go back to it again later.)

See above, ports isn't tied to base releases and never has been AFAIK.
There were technical options to extend the time, the simplest being:
Don't update the ports tree!

Bring in security updates manually is a lot easier than migrating 50
servers and it's not that big a deal for a few months, and as I said, I
am sure your organisation could have paid a reasonable amount for
somebody to do it for you.

> Well I didn't know - despite following the conversations on the public
> lists - until 3 weeks before the event that the change was going to
> deliberately and irrevocably break the old systems... again...


As I said, I sympathize, but are you really going to point the fingers
at others before yourself here?


> Dunno about Roger, but I am and I had been campaigning internally about
> getting support for FreeBSD as a platform and support for the foundation
> in the way of devs and/or cash...  that is *never* going to happen now. 
> Money has been allocated and sent to Redhat (nothing to do with me, but
> the pkgng debacle left me without legs to argue the case, so the
> decision makers stuffed that.)

And the next linux-related fiasco experiences can be traced back to a
rash and technically questionable decision by all involved.  Good luck I
guess.  And what was the cost of the transition and what will be the TCO
over the next 10 years?  None of that money would have been better spent
on the encumbent system.  That's really hard to believe.


> That I can't (and won't) comment on, but I will tell you that's the
> reason all new servers I manage are being installed with CentOS+paid
> support contract and not FreeBSD+donation.  The bed was made by people,
> they can sleep in it.

And you probably spent magnitudes more than just getting a consultant to
help for a few months for a few hours a month.  It's easy to say
foundation would have gotten money but harder to believe if they never
got a donation in the past when everything was working okay, right?

John



___
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: Removing documentation

[Roger Marquis]

So, if it was too burdensome for the whole project to support
two trees (that probably was the estimate for the core developers
involved [and I'm not one of them]), why, do you think, would
it have worked for a sub-fraction of the project ?


Thanks Kurt, for cutting to the core issue.  It's one that has dogged
FreeBSD for some time now i.e., to either A) manage change-control with a
long term perspective with the goal of growing or at least retaining the
installed base of end-users or B) with a short-term perspective for the
benefit of our generous and skilled developers.


From a strictly end-user perspective I'd prefer if the skew went a little

more towards former (long-term planning) for both selfish (more FreeBSD
jobs) and shared (more stability, better security, fewer bugs) goals.
There's no getting around the budget, however, and hope that FreeBSD's
long-term viability plays a larger part in at least the Foundation's
efforts.

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: Removing documentation

[John Marino]

On 2/15/2016 6:32 PM, Roger Marquis wrote:
>> This makes no sense.  Ports are not tied to base releases.
>> And you think lack of developer resources is an invalid reason?
> 
> There was no mid-release issue with base as far as I know.  The issue was
> with ports and by extension pkgng (and related -ngs).

ports are developed independently.  They do not follow release
schedules.  Ports have to support all supported releases, that's the
only connection.

To say ports support has to coincide with a base release schedule shows
a lack of understanding of ports development process.  It also doesn't
account for 3 concurrent releases (or 2 releases and -CURRENT) which are
not synchronized.



> was dated Feb 3 2014, leaving all of 7 months until the planned
> deprecation.  Even if you could make a case that pkgng was ready (it
> wasn't) 7 months is far less than the 2 calendar year and dozens of
> person-year cycles required by some infrastructure-critical production
> environments.  It's even farther from the 7+ years that other FOSS
> distributions support their releases.

what FOSS distributions support releases for 7+ years for gratis?  One
pays for that kind of support.  Did your organization offer to pay for
extended support?


>> It's a business, right?  You aren't talking about a shoestring hobby.
> 
> There's no need to shoot the messenger here.  I may be expressing an
> opinion but it is one that is shared by all of my colleagues: developers,
> administrators and managers alike.

All your colleagues, developers, administrators, and managers want
enterprise level support without paying any money at all?   They *all*
think volunteers provide that level of support just because?  This is
not messenger-shooting, this is wondering what kind of place has
expectations like that.

I've never worked at a place like that.

John
___
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: Removing documentation

[Roger Marquis]

This makes no sense.  Ports are not tied to base releases.
And you think lack of developer resources is an invalid reason?


There was no mid-release issue with base as far as I know.  The issue was
with ports and by extension pkgng (and related -ngs).


You know good and well that people kick the can down the road FOREVER.
You could have announced it 3 years ahead and people would still scream
NOT YET!  NOT YET!  This would NEVER happen in Linux!


The announcement

was dated Feb 3 2014, leaving all of 7 months until the planned
deprecation.  Even if you could make a case that pkgng was ready (it
wasn't) 7 months is far less than the 2 calendar year and dozens of
person-year cycles required by some infrastructure-critical production
environments.  It's even farther from the 7+ years that other FOSS
distributions support their releases.


It's a business, right?  You aren't talking about a shoestring hobby.


There's no need to shoot the messenger here.  I may be expressing an
opinion but it is one that is shared by all of my colleagues: developers,
administrators and managers alike.

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: Removing documentation

[Michelle Sullivan]

John Marino wrote:
> On 2/15/2016 5:59 PM, Roger Marquis wrote:
>   
>> It was actually worse than that.  Those of us who questioned the wisdom
>> of such disruptive and backwards-incompatible changes being implemented
>> mid-release instead of at a release boundry were A) ignored, B) told that
>> there were not enough (developer) resources, and C) even the announcement
>> was unprofessional and lacked justification for the rush job:
>> 
>
> This makes no sense.  Ports are not tied to base releases.
> And you think lack of developer resources is an invalid reason?
>   

Actually it made perfect sense... (for a change) ... make pkgng the
default on 10.x and allow people to use either on 8.4 and 9.x ...  this
made perfect sense...  Make base packaging using similar/same tools as
part of 11+ makes perfect sense... 


No, though... arbitrary date set, f**k real users, f**k whether it
works or not, because we need people to put it in production so we can
test our buggy software...

>
>   
>>   There comes a time in the life cycle of just about every software
>>   package that it has bee re-evaluated, refreshed, deprecated or just
>>   retired.
>>
>>   It is time that we bid farewell to the old pkg_* software that has been
>>   part of FreeBSD since the beginning, and has served us well.  After
>>   years of development, testing, and playing, pkg(8) has become a
>>   suitable replacement.
>>
>> "there comes a time"?  "time that we bid farewell"?  These are not
>> suitable criteria IMO for dropping support of mission-critical
>> subsystems.  The FreeBSD Foundation SHOULD have played a part in insuring
>> a smoother transition to pkgng (much less portsng and, gack, rcng) but
>> this doesn't seem to have been on their radar.
>> 
>
> You know good and well that people kick the can down the road FOREVER.
> You could have announced it 3 years ahead and people would still scream
> NOT YET!  NOT YET!  This would NEVER happen in Linux!
>
> It doesn't matter where you draw the line, you will never get everyone
> to respect it.  It's never enough time.
>   

Line drawn - at the next major version...  that's an easy win... people
can complain, but they can't argue that it isn't a good decision because
they can choose... upgrade/don't upgrade... we didn't get the chance to
choose ... it was forced down peoples necks... working or not. 
Fortunately I was able to get the old system working again... and in
fact keep it up to date until about 3 months ago... (and only stopped
there because I have other things to do - will go back to it again later.)

>>> From my perspective as an advocate and long-time user (since 2.0.5) this
>>>   
>> marked a low-point in the viability of FreeBSD vis-a-vis other FOSS
>> distributions.  Thankfully, going forward from FreeBSD 11 the release
>> cycle has been lengthened and base is going to be packaged.  Those of use
>> who support large numbers of dev and production systems can at least
>> expect that future upgrades won't be as time-consuming or, hopefully, as
>> buggy.
>> 
>
> "large numbers of dev and production systems" (push to memory stack)
>
>
>
>   
>> I believe this is factually incorrect.  We were aware but the decisions
>> were being made by core developers who were not, apparently, interested
>> in our concerns or the expected fallout.
>> 
>
> So you chose to ignore the deadlines in the hopes the pleading would
> work?  You intentionally did not prepare against the published timetable?
>   

Well I didn't know - despite following the conversations on the public
lists - until 3 weeks before the event that the change was going to
deliberately and irrevocably break the old systems... again...

>
>   
>>> There was always the option of freezing the tree and pulling in the
>>> security updates manually until you were ready to migrate to pkg(8) too.
>>>   
>> Sure, if you can afford to pay a full-time core dev there's the option of
>> backporting but even this was made impractical by the simultaneous
>> deprecation of the pre-ng ports tree, make version and pkg format.
>> 
>
> No, it's not fully time.  You just said "large numbers of dev and
> production systems", so I am pretty confident the business case would
> have been there for this.
>
> It's a business, right?  You aren't talking about a shoestring hobby.
>   

Dunno about Roger, but I am and I had been campaigning internally about
getting support for FreeBSD as a platform and support for the foundation
in the way of devs and/or cash...  that is *never* going to happen now. 
Money has been allocated and sent to Redhat (nothing to do with me, but
the pkgng debacle left me without legs to argue the case, so the
decision makers stuffed that.)

>> There are lots of reasons why Linux has effectively eclipsed BSD
>> including device drivers, unattended deployments and install menus but
>> 8.X's wholesale throwing of so many of us under the bus was by far the
>> worst.
>> 
>
> And now the fully circle.  

Re: Removing documentation

[Kurt Jaeger]

Hi!

> The FreeBSD Foundation SHOULD have played a part in insuring
> a smoother transition to pkgng (much less portsng and, gack, rcng) but
> this doesn't seem to have been on their radar.

I don't know if it was on their radar, but I saw at that time that
the community lost users due to the technical debt of the old
pkg_* stuff. And it lost developers because the old way was too
burdensome.

> I believe this is factually incorrect.  We were aware but the decisions
> were being made by core developers who were not, apparently, interested
> in our concerns or the expected fallout.

Those two are seperate things:

- Being interested
- having enough communication bandwidth
  (== time to spend on mailing lists argueing back and forth)

So, what should a poor core developer do, given this choice ?

I don't think that too many core developers were left doing
the work.

> > There was always the option of freezing the tree and pulling in the
> > security updates manually until you were ready to migrate to pkg(8) too.

> Sure, if you can afford to pay a full-time core dev there's the option of
> backporting but even this was made impractical by the simultaneous
> deprecation of the pre-ng ports tree, make version and pkg format.

So, if it was too burdensome for the whole project to support
two trees (that probably was the estimate for the core developers
involved [and I'm not one of them]), why, do you think, would
it have worked for a sub-fraction of the project ?

> There are lots of reasons why Linux has effectively eclipsed BSD
> including device drivers, unattended deployments and install menus but
> 8.X's wholesale throwing of so many of us under the bus was by far the
> worst.

Indeed, it was a cruel choice. Someone had to decide.

-- 
p...@opsec.eu+49 171 3101372 4 years to go !
___
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: Removing documentation

[John Marino]

On 2/15/2016 5:59 PM, Roger Marquis wrote:
> It was actually worse than that.  Those of us who questioned the wisdom
> of such disruptive and backwards-incompatible changes being implemented
> mid-release instead of at a release boundry were A) ignored, B) told that
> there were not enough (developer) resources, and C) even the announcement
> was unprofessional and lacked justification for the rush job:

This makes no sense.  Ports are not tied to base releases.
And you think lack of developer resources is an invalid reason?


>   There comes a time in the life cycle of just about every software
>   package that it has bee re-evaluated, refreshed, deprecated or just
>   retired.
> 
>   It is time that we bid farewell to the old pkg_* software that has been
>   part of FreeBSD since the beginning, and has served us well.  After
>   years of development, testing, and playing, pkg(8) has become a
>   suitable replacement.
> 
> "there comes a time"?  "time that we bid farewell"?  These are not
> suitable criteria IMO for dropping support of mission-critical
> subsystems.  The FreeBSD Foundation SHOULD have played a part in insuring
> a smoother transition to pkgng (much less portsng and, gack, rcng) but
> this doesn't seem to have been on their radar.

You know good and well that people kick the can down the road FOREVER.
You could have announced it 3 years ahead and people would still scream
NOT YET!  NOT YET!  This would NEVER happen in Linux!

It doesn't matter where you draw the line, you will never get everyone
to respect it.  It's never enough time.


>> From my perspective as an advocate and long-time user (since 2.0.5) this
> marked a low-point in the viability of FreeBSD vis-a-vis other FOSS
> distributions.  Thankfully, going forward from FreeBSD 11 the release
> cycle has been lengthened and base is going to be packaged.  Those of use
> who support large numbers of dev and production systems can at least
> expect that future upgrades won't be as time-consuming or, hopefully, as
> buggy.

"large numbers of dev and production systems" (push to memory stack)



> I believe this is factually incorrect.  We were aware but the decisions
> were being made by core developers who were not, apparently, interested
> in our concerns or the expected fallout.

So you chose to ignore the deadlines in the hopes the pleading would
work?  You intentionally did not prepare against the published timetable?



>> There was always the option of freezing the tree and pulling in the
>> security updates manually until you were ready to migrate to pkg(8) too.
> 
> Sure, if you can afford to pay a full-time core dev there's the option of
> backporting but even this was made impractical by the simultaneous
> deprecation of the pre-ng ports tree, make version and pkg format.

No, it's not fully time.  You just said "large numbers of dev and
production systems", so I am pretty confident the business case would
have been there for this.

It's a business, right?  You aren't talking about a shoestring hobby.


> There are lots of reasons why Linux has effectively eclipsed BSD
> including device drivers, unattended deployments and install menus but
> 8.X's wholesale throwing of so many of us under the bus was by far the
> worst.

And now the fully circle.  This is FreeBSD's Godwin's law.  You know the
discussion is over when somebody says that "[issue] of the day" is the
root cause of BSD being eclipsed by Linux.  Since I've heard [issue]
replaced about 200 times, I'm kind of doubting it.  I guess it's purpose
is to make everyone involved with "[issue]" to feel personally
responsible and oh what could have been if you hadn't of made the wrong
decision



___
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: Removing documentation

[Roger Marquis]

Michelle wrote:

The way it was forced down everyone's necks pushed it to 8.4 and 9.x
systems as well as 10.x, this was a bad decision.  It was a decision
made by someone who doesn't live in the real world of production servers
and production services...


It was actually worse than that.  Those of us who questioned the wisdom
of such disruptive and backwards-incompatible changes being implemented
mid-release instead of at a release boundry were A) ignored, B) told that
there were not enough (developer) resources, and C) even the announcement
was unprofessional and lacked justification for the rush job:

  There comes a time in the life cycle of just about every software
  package that it has bee re-evaluated, refreshed, deprecated or just
  retired.

  It is time that we bid farewell to the old pkg_* software that has been
  part of FreeBSD since the beginning, and has served us well.  After
  years of development, testing, and playing, pkg(8) has become a
  suitable replacement.

"there comes a time"?  "time that we bid farewell"?  These are not
suitable criteria IMO for dropping support of mission-critical
subsystems.  The FreeBSD Foundation SHOULD have played a part in insuring
a smoother transition to pkgng (much less portsng and, gack, rcng) but
this doesn't seem to have been on their radar.


From my perspective as an advocate and long-time user (since 2.0.5) this

marked a low-point in the viability of FreeBSD vis-a-vis other FOSS
distributions.  Thankfully, going forward from FreeBSD 11 the release
cycle has been lengthened and base is going to be packaged.  Those of use
who support large numbers of dev and production systems can at least
expect that future upgrades won't be as time-consuming or, hopefully, as
buggy.

John Marino wrote:

Michelle, I sympathize, but you're also not taking any responsibility
for that situation.  All those transitions were announced years in
advance.  I seem to recall you were completely unaware of those plans,
and if that is accurate, it's something you should have been aware of as
the administrator of real world production servers.


I believe this is factually incorrect.  We were aware but the decisions
were being made by core developers who were not, apparently, interested
in our concerns or the expected fallout.


There was always the option of freezing the tree and pulling in the
security updates manually until you were ready to migrate to pkg(8) too.


Sure, if you can afford to pay a full-time core dev there's the option of
backporting but even this was made impractical by the simultaneous
deprecation of the pre-ng ports tree, make version and pkg format.

There are lots of reasons why Linux has effectively eclipsed BSD
including device drivers, unattended deployments and install menus but
8.X's wholesale throwing of so many of us under the bus was by far the
worst.

IMO,
Roger Marquis
___
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: Removing documentation

[Michelle Sullivan]

Steven Hartland wrote:
> On 14/02/2016 11:25, Michelle Sullivan wrote:
>> Kevin Oberman wrote:
>>> My experience is that pkg(8) has been wonderfully robust since 1.3.
>>> before
>>> 1.3 it was a real pain in the neck, though I never had a need to
>>> rebuild
>>> the DB, I did ave to do a bit of fix-up. I really, really wish Bapt had
>>> listened and held up the default to pkg for a bit. Much as I like
>>> it, it
>>> really was not ready for prime time when it became the default. The
>>> early
>>> issues chased too many people away. E.g. you.
>>>
>> Nailed it!
> The problem with that is its a chicken and egg situation, without it
> hitting prime time it likely wouldn't have got the needed use to
> identify and subsequently fix the issues you're referring to; at the
> very least it would have slowed that process down :(

You're wrong.  It was the default in 10.x ... as people upgraded to 10.x
it would have gotten more and more exposure, slowly and more controlled.

The way it was forced down everyone's necks pushed it to 8.4 and 9.x
systems as well as 10.x, this was a bad decision.  It was a decision
made by someone who doesn't live in the real world of production servers
and production services... 

The results were the same as back in the 7.x days when the last "ports"
change happened making it incompatible with previous versions of
FreeBSD  

...Systems out there stopped updating (getting updated)...

...Systems out there are now a security risk with 'FreeBSD' written on
the front door...

...Some of the FreeBSD systems that were out there now run Solaris or
CentOS (because we know that despite how much of a pain the fricken'
butt and expensive to maintain, it's better than the expense connected
when some developer out in their small world of running a blog server
that thinks they know how to administer production servers says, "You
know what we're just going to change the base way software (and
therefore patch) management works in the OS across your production
environment...  because we need more people to test our software.")

Anyhow, too late now the damage has been done and there is no way to get
the goodwill back or repair that damage now.

Regards,

-- 
Michelle Sullivan
http://www.mhix.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: Removing documentation

[Kevin Oberman]

On Sun, Feb 14, 2016 at 3:37 AM, Steven Hartland 
wrote:

> On 14/02/2016 11:25, Michelle Sullivan wrote:
>
>> Kevin Oberman wrote:
>>
>>> My experience is that pkg(8) has been wonderfully robust since 1.3.
>>> before
>>> 1.3 it was a real pain in the neck, though I never had a need to rebuild
>>> the DB, I did ave to do a bit of fix-up. I really, really wish Bapt had
>>> listened and held up the default to pkg for a bit. Much as I like it, it
>>> really was not ready for prime time when it became the default. The early
>>> issues chased too many people away. E.g. you.
>>>
>>>
>> Nailed it!
>>
> The problem with that is its a chicken and egg situation, without it
> hitting prime time it likely wouldn't have got the needed use to identify
> and subsequently fix the issues you're referring to; at the very least it
> would have slowed that process down :(
>
> Regards
> Steve
>

Sorry, but I'm afraid not.

There was spirited discussion at the time about the weaknesses and problems
with pkg. It finally came to a head over portmaster. Its author and
maintainer refused to put revisions to support pkg(8) because he felt
strongly that issues with it had to be dealt with first.

To be clear, I was one of those who wanted more development before making
pkg the default. I really, really wanted pkg to help me deal with issues at
work with maintaining FreeBSD that led to its replacement with Linux. As
much as I wanted pkg, it seemed clear to me that it needed more work.
Obviously, I was not on the winning side and there is no going back now
that pkg has become a stable and robust tool that was critical to the
growth of FreeBSD.
--
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: Removing documentation

[Steven Hartland]

On 14/02/2016 11:25, Michelle Sullivan wrote:

Kevin Oberman wrote:

My experience is that pkg(8) has been wonderfully robust since 1.3. before
1.3 it was a real pain in the neck, though I never had a need to rebuild
the DB, I did ave to do a bit of fix-up. I really, really wish Bapt had
listened and held up the default to pkg for a bit. Much as I like it, it
really was not ready for prime time when it became the default. The early
issues chased too many people away. E.g. you.
   

Nailed it!
The problem with that is its a chicken and egg situation, without it 
hitting prime time it likely wouldn't have got the needed use to 
identify and subsequently fix the issues you're referring to; at the 
very least it would have slowed that process down :(


Regards
Steve
___
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: Removing documentation

[Michelle Sullivan]

Kevin Oberman wrote:
>
> My experience is that pkg(8) has been wonderfully robust since 1.3. before
> 1.3 it was a real pain in the neck, though I never had a need to rebuild
> the DB, I did ave to do a bit of fix-up. I really, really wish Bapt had
> listened and held up the default to pkg for a bit. Much as I like it, it
> really was not ready for prime time when it became the default. The early
> issues chased too many people away. E.g. you.
>   

Nailed it!


-- 
Michelle Sullivan
http://www.mhix.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: Removing documentation

[Michelle Sullivan]

Kurt Jaeger wrote:
> Hi!
>
> Michelle wrote:
>   
>> ports (post pkg) from source: exactly the same problems as pre-pkg plus
>> occasionally the DB would get corrupted and then you have to nuke the
>> entire package system from orbit and reinstall all the ports.
>> 
>
> Interestingly, I had my cases of strange dependencies chains, but
> I can't remember a case where the pkg-db was really trashed to no
> longer function.
>
> The more recent pkg versions are very robust for my use cases.
>
>   
It was earlyish (first 6-9 months) in the "you're going to use this now
whether you like it or not and whether it works or not phase".. since
then I've made the ports system work with pkg_tools again so no longer
have anything to do with pkg.  Its a good stop-gap until I can get the
build environment integrated into the CentOS one @ $employer.

-- 
Michelle Sullivan
http://www.mhix.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: Removing documentation

[John Marino]

On 2/14/2016 8:07 AM, Kevin Oberman wrote:
> ery update to the port going back to the version when the options file
> was created, 1.9a_1. Comparing that to the current version, there have
> been no options changes at all. Not to the options offered nor to the
> defaults. I am baffled as to what is going on. Looks like portmaster
> might be doing this a bit better than synth does.

Send me the tmux options file.
The mystery should not be hard to crack.  We can just look at the data.
___
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: Removing documentation

[Kevin Oberman]

On Wed, Feb 10, 2016 at 2:57 PM, Alphons van Werven 
wrote:

> John Marino wrote:
>
> > Well, if I make the assume that Kevin has been using portmaster, and
> > that using Synth revealed 42 obsolete cached configurations, I would
> > have to conclude PM doesn't do this anymore or does it very poorly and
> > misses a large number of configs.
>
> Using the latest version of Portmaster, I feel confident in stating that
> the "doesn't do this anymore" part appears to be false. My money is on
> incomplete detection, i.e. detecting only a subset (but doing at least
> that part correctly) of all possible kinds of option changes.
>
> However, I did not intend to sidetrack the discussion. As previously
> mentioned, it's just an observation.
>
> Fonz
>

Well, I just tracked down the details for sysutils/tmux. I picked it
because it was at the bottom of the list.

I checked every update to the port going back to the version when the
options file was created, 1.9a_1. Comparing that to the current version,
there have been no options changes at all. Not to the options offered nor
to the defaults. I am baffled as to what is going on. Looks like portmaster
might be doing this a bit better than synth does.
--
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: Removing documentation

[Kevin Oberman]

On Sat, Feb 13, 2016 at 2:29 AM, Michelle Sullivan 
wrote:

> Kurt Jaeger wrote:
> > Hi!
> >
> > Michelle wrote:
> >
> >> ports (post pkg) from source: exactly the same problems as pre-pkg plus
> >> occasionally the DB would get corrupted and then you have to nuke the
> >> entire package system from orbit and reinstall all the ports.
> >>
> >
> > Interestingly, I had my cases of strange dependencies chains, but
> > I can't remember a case where the pkg-db was really trashed to no
> > longer function.
> >
> > The more recent pkg versions are very robust for my use cases.
> >
> >
> It was earlyish (first 6-9 months) in the "you're going to use this now
> whether you like it or not and whether it works or not phase".. since
> then I've made the ports system work with pkg_tools again so no longer
> have anything to do with pkg.  Its a good stop-gap until I can get the
> build environment integrated into the CentOS one @ $employer.
>
> --
> Michelle Sullivan
> http://www.mhix.org/


My experience is that pkg(8) has been wonderfully robust since 1.3. before
1.3 it was a real pain in the neck, though I never had a need to rebuild
the DB, I did ave to do a bit of fix-up. I really, really wish Bapt had
listened and held up the default to pkg for a bit. Much as I like it, it
really was not ready for prime time when it became the default. The early
issues chased too many people away. E.g. you.

I've had exactly zero issues since shortly after 1.4 was released. 4.1 bit
me rather painfully, but was quickly fixed, as I recall. (N.B. This is all
from memory as my records and notes went away when I retired.)
--
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: Removing documentation

[Torsten Zuehlsdorff]

On 12.02.2016 07:21, Royce Williams wrote:


I'm advocating that we stop quasi-providing four different flavors of
apt-get.  Until there is a single and official mechanism for both
dependency resolution and configuration option management, the
fragmentation remains.


Why do you think this is the case?  Ports defines the dependencies and
pkg respects them.  I'm not seeing where there more than one method
here.  What other ones are there?



The current ports/pkg relationship is still fragile, perhaps because
it's new.  I almost abandoned FreeBSD entirely a couple of months ago
when an interesting corner case of the use of pkg managed to
unilaterally and without warning delete in its entirety the contents
of /usr/local/etc/rc.d in of my jails.

Contrast this with the Ubuntu world, where there is a well-baked
"unattended-upgrades" option that automatically downloads and upgrades
all security updates for both the OS and all third-party packages.


These are not well-baked, i did find multiple problems with them.

Also this is *not* something you really want. If security really is 
important you do not install software without your explicit approval. 
There are to many things which can go wrong and normally do. These 
complains are often in the Ubuntu world.


The Ubuntu world is not so bright as you say. ;)

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: Removing documentation

[Torsten Zuehlsdorff]

On 12.02.2016 01:41, John Marino wrote:

On 2/12/2016 1:22 AM, Royce Williams wrote:

Is the abstraction is happening at the equivalent level here? The
platforms that I'm thinking of -- that appear to have already solved
this entire class of problem long ago -- feature wrappers around
apt-get, not wrappers around dpkg.


I'm not a linux guy so those things don't mean much the me.  The
abstraction layer here is at the appropriate level.  I'm not seeing this
fragmentation problem you're talking about, at least not with the newer
tools.


I agree in this point with John. Also a clear "no" to the statement, 
that this problems are solved with apt-get or other tools in the Linux 
world. This is clearly not true.


Did you, Royce, ever try to build something from the source and register 
it in the packet manager around dpkg? Build your own binary repository 
and mix it with others? Yes, FreeBSD did miss some features - but for 
the most use-cases it is much more reliably and flexible than the tools 
named by you, Royce.


Whenever i bring up a comparison between the packet managers there is a 
clear win for FreeBSD voted by the Linux guys. Most time winning points 
are something simple like "pkg audit write you an email if there is a 
security issue". Or having a portstree in an code-repository and 
therefore the possibility to just go back in time. Or easy 
change/storable configuration files.



If there were no ports system, and everything was package-driven, I'd

agree.  Synth and its cousins exist because people work from ports --
which means that dependencies matter.


Synth exist because people are insisting to build from source (even
irrationally) so they might as well do it correctly.  The statement
above doesn't have anything to do with Synth being a binary.

If a shell script was so good, why is portmaster unmaintainable?


It is not unmaintainable. But it is not written in a manner which make 
maintenance very easy. But this is sadly true for most software...


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: Removing documentation

[Lev Serebryakov]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 12.02.2016 03:22, Royce Williams wrote:

> As long as the ports system exists (and I think it should!), the 
> management of compilation requirements -- especially for something 
> that might need to be bootstrapped early, like a software
> management tool -- is a valid topic.
 THIS.

- -- 
// Lev Serebryakov
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQJ8BAEBCgBmBQJWvc9dXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRGOTZEMUNBMEI1RjQzMThCNjc0QjMzMEFF
QUIwM0M1OEJGREM0NzhGAAoJEOqwPFi/3EeP6gIP/iwlLoySKsPTglpVPu9nEvwI
hW2OVyVjp2Kk0nvQwARQ76jSgJ/b9ze4m9zQAPPLxgwoaCP05AlLUrGf2XmQmD5r
Qxd5VmaLx1qc8IMh7Aa+FszEqcsgNW1j90nL/4YVD9xVydLSiuPSgsIxqagkuk/s
FsB3Y0ZHMSEvEv6yheOujHCUmB/poHdZl9sM7bJd1+OlAoWr9ePFu+crnceelgF1
qSdWYingjvaKKABBzkaRpAWAIC/doZ1HifPSbpNROcovWD23KMr466Ldg+I1n8rQ
gQVzN4bQJ8jXmvz+8wchOMQQB47igGDY6fjGbZ9rU1VjC8XvhF35qSsYea59bBZ8
WJMuCNeSGQtcgkd7J5WqSZQTzxOLQK+NMruw/tjl0NrjOvyFGSLBn9gUJoUQtOpD
NN+AVq11eooTWV3MpbpCkoxvyS0a1a7znUmaHT64YvtSua9xK4lFqWdBrF07te8h
UMMuLzSizOvlONDi4WNgBIRbBYGo7uurdFQrAbVkaSCBGgRqTPwaR4CpCq+rtsOj
OEr+TY1k33pBa2bsc9z5Rnjs3X8OW+Lc6CURrnqnDpiIGpZuL+qkTYQ2Ig4wp+Ip
NIBSL48sugVKHtMRfFmp/ycgUiyWX6N3Mc6zrj4/RosbiJVp2c7AmDi5VCGNlMMc
oXvZ+lroIy6Y1opC+Oue
=PgK+
-END PGP SIGNATURE-
___
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: Removing documentation

[John Marino]

On 2/12/2016 1:26 PM, Lev Serebryakov wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
> 
> On 12.02.2016 03:22, Royce Williams wrote:
> 
>> As long as the ports system exists (and I think it should!), the 
>> management of compilation requirements -- especially for something 
>> that might need to be bootstrapped early, like a software
>> management tool -- is a valid topic.
>  THIS.

What "This"?
He was wrong.  There's no bootstrapping.  It doesn't apply.  You are
"thumbs up"ing a fallacy.  It makes no sense at all.  I am sure is
sounds great though.
___
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: Removing documentation

[John Marino]

On 2/12/2016 1:29 PM, Lev Serebryakov wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
> 
> On 12.02.2016 03:41, John Marino wrote:
> 
>> THERE'S NO REQUIREMENT THAT SOMETHING THAT BUILDS PORTS NEEDS THAT 
>> ITSELF IS BUILT FROM PORTS.  You responded to something different.
>   If I want to use binary packages, I don't need synth, right? If I
> want to use ports, I want to use ports, not binary package for synth +
> ports. It is funny and annoying, that tool to manage PORTS better be
> installed NOT FROM PORTS (or you need another toolchain not in base
> system).
> 
>  It is not strict requirement, yes.

It is another fallacy.
1) you don't need Synth at all.  It's a luxury for people that want
things correct on their system.  For people that are happy with risks
(whether they choose to recognize and/or acknowledge them or not), PM
and live-building from source is still available.

2) Anybody with a strict "I don't take packages at all" policy have much
bigger concerns than building one more gcc.  Their policy will hit them
all over the place, so the "joke" here is the objection.  You'll build
everything you need from the entire tree, but you draw the line at one port?

It is illogical to have that policy and then complain about the obvious
consequences of that policy.

___
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: Removing documentation

[Lev Serebryakov]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 12.02.2016 00:32, Matt Smith wrote:

>>> ports-mgmt/synth.  I would love to hear what signficant thing 
>>> portmaster can do that Synth can't.  (honestly)
>> Be installed FROM PORTS without all this build-one-more-gcc
>> stuff. Ada? For *port*management* tool? Are you joking?
> 
> Remember that before portmaster we had cvsup which was written in 
> Modula-3 and portupgrade which is written in Ruby. Whilst it is
> nice that portmaster is just a simple shell script with no
> dependancies that's a relatively new thing.
 I remember cvsup (great tool, for sure) as
only-binary-package-on-my-self-build-system, yes. And it annoyed me a
bit every time, that I need to download binary package :)

- -- 
// Lev Serebryakov
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQJ8BAEBCgBmBQJWvc7ZXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRGOTZEMUNBMEI1RjQzMThCNjc0QjMzMEFF
QUIwM0M1OEJGREM0NzhGAAoJEOqwPFi/3EePDrUP/33yYFNyrBKwfeSXQwxuqHZ7
l9VlJFzEwSGqM4pXstYZjkrv8MGYTbfpD9KLd2vURClTO3J9QU1FNugRw+8XkLi3
4sekwg3sxfN+vVIYvB/Oy5lcvl3u6sdOt8SRar5OYVkpoqhE0PHYeGpyCUT45BXy
RgdZFeQiBjwsxR2cphZtNbeLJPZiZ+fROfFZdfWM5VB5XtPAGrRybYQbCnngMEPb
lr84Sdi7yMk1n2LOPUnhpTK1XROn1HcX5EOozhaWmQ3fpV741ji3YvnglwoFbqc2
hOEiPsfrSHFy7Pnykqi0GWyF+QVzSk9xMiuLQjdTBFOjuHlIjJt6oWjBsrDfj+Ki
ee2UFN3RgNQhM7gIammfiVJSA1RHlqU9JH8Xn0fihhDgytVZoehmmwXLa3FfMZOJ
EAC6kpxG+npJaqJcSsDebyTf+8yTfvBegVEhi+a84EIXQgQr5GqMAPoH/RZgkACE
VK+Odc8JvLFGQr5ytOO76N3gl4hcb+07stmrfLmtsoUzNL7mFcgSLQ64TDBTqXML
MMBABec/h75XpuWCmCKE2DPSzEhD9D7khoj41no0pRnLf8En9n5FXnqedLCczCmN
GwC7av++WeXrMKnBO4wS4vwGNnwO5rdOB6SaL3k1qFCYwEk+z8rWLz+VLPKsDhER
uPUiFcyU/BG8hSzV8aqW
=9MbF
-END PGP SIGNATURE-
___
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: Removing documentation

[Lev Serebryakov]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 12.02.2016 03:41, John Marino wrote:

> THERE'S NO REQUIREMENT THAT SOMETHING THAT BUILDS PORTS NEEDS THAT 
> ITSELF IS BUILT FROM PORTS.  You responded to something different.
  If I want to use binary packages, I don't need synth, right? If I
want to use ports, I want to use ports, not binary package for synth +
ports. It is funny and annoying, that tool to manage PORTS better be
installed NOT FROM PORTS (or you need another toolchain not in base
system).

 It is not strict requirement, yes.

- -- 
// Lev Serebryakov
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQJ8BAEBCgBmBQJWvdA2XxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRGOTZEMUNBMEI1RjQzMThCNjc0QjMzMEFF
QUIwM0M1OEJGREM0NzhGAAoJEOqwPFi/3EePjm4QAI0XoT+CBh8Sp/XZuxoEgkyJ
idXTuCgAC3OakonHLEe7Ng4JbDwcdGQbiOhY1pv4lINNea+wpnjuJXfnf4yGeV+E
QZblLvfaDPZBISrvV7AScvHiu8D6atgXNlop+pJQo0uV3yQE+susKUYIrP3vbptO
4Ap6X6wEYNyr3eKHkhgOnT+5kW1vrdphxU74bvq7J6u0LY6U8Oh3DvFITuBNCDIb
M7Ug9o4uu+J+BouXnJw70sGJnDzHM9VdrLvki2Zj8R9/WcOukxzkr3v2G7khi2cE
5DINj2daXT7J8XgFwpbBgkfPSRJSM0so0+OdRnTEFXf17mJOyY2VI530cwz928IW
6aH9RQr4eaBNyHpRzMTT5JNXK4LcKA4HDQmr2xP+lI+j1YMEJJ//5B/vb4yTwrFl
Zh2ueC2T1oZIAOl8xjpbGfepjaNG7KosCXdvKKjYGp84iNnbq+W5D9dt+0Tng1A6
EhrfzUmDjwz1aYOlDqPlvFTAeNr9z0ISFrElY/IE+2bdk/R/zvRLKy1LTadW0i4n
yMeQbezQPXIkEQBDH3S0wFYB3na+W4viA7lcy+3scDxo9NvxdAk7CH4WDvYFsKqU
Bgc45QT1nKaThutNU6wc/4eyv2Bb+/qkvpEXCtky+IKPXb1eBMSMmrcZeTfffz2L
qweGy/WcL93Nfwp08uHi
=4QJQ
-END PGP SIGNATURE-
___
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: Removing documentation

[Lev Serebryakov]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 11.02.2016 22:33, John Marino wrote:

>>> ports-mgmt/synth.  I would love to hear what signficant thing 
>>> portmaster can do that Synth can't.  (honestly)
>> Be installed FROM PORTS without all this build-one-more-gcc
>> stuff. Ada? For *port*management* tool? Are you joking?
> 
> Let me guess.  You've spent actually 0.0 nanoseconds preparing on
> the subject before providing this enlightened take for the list.
 Ok, let me expand.

 I see here contradiction. There are people who prefer binary
packages. There are people who prefer ports (local builds). Both ways
are perfectly Ok to me. I'm prefer ports, because I have only a few
full-featured FreeBSD installations, and I don't like many ports
options defaults (=packages defaults). If I have much more FreeBSD
hosts, it could be worth for me to have one custom package repository,
but in my particular case, it isn't worth it.

 So, ports. If I'm using ports, I want to use ports. Not "install this
from package and that from ports". And in such situation I want to
have set of "non-productive" ports (which doesn't solve server's
problem, but bookkeeping ones) minimal. This includes all these
auto*-crap, gmake, texinfo, and other build-depends. And have here
port-to-manage-ports which needs one-more-bloated-gcc-toolachain is
not what I want. And I need to have it here, because there will be
moment in time when I'll upgrade (rebuild!) synth itself.

 Synth could be great package for build server. I'll give it a try to
build packages for NanoBSD images, for example (instead of poudriere),
for sure. But not fore my ports-based installations.

- -- 
// Lev Serebryakov
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQJ8BAEBCgBmBQJWvc44XxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRGOTZEMUNBMEI1RjQzMThCNjc0QjMzMEFF
QUIwM0M1OEJGREM0NzhGAAoJEOqwPFi/3EePna4P/2GsGsFvhvSQgxyztBiPhnAL
TEcgI3tSsHlzezpDXpHbd8R6SpZF+afvTku09gw7NwlQqdyu2HcvNcX6z2Ss6nLD
f0GeqM44bvcSN4b43FVfrkqgo3haCcuy05ocC3a76sE3ZgGDiSLnuY7HPn6ndLCa
32+zFcYzsc9MZoZKUoWl6FtnkEANHag/iTU3o1RXk19JErwZ1ZOEzVgc+Spov5GQ
vF2Abx7EZV+CI7mwxHRbwt6/Si1kLDBjA9V/GAH6UTXGAiTDSn6z7zgNrvjWy6SY
0UoHho+yUxKYmH4cUU4g+PHIhPJrOQHu39bXd0jzdQq2rSODgYV/Lg5EEjACRaEP
DWvnlK/TNDFQGz7+1MU5TeLdtLJ49b7Z7eEGSNrhKDBmkuRakUkDZ/fHBWiztBuK
ZquIvsb/L7SdHGCh0ax4SCJJRQ6ynKQ9SWaXBBtqgbWfUvLhp2Jd2vaON3AyfT6j
ihxEFmuLD0P3VIEHvoVA3SKuOXLA4boLhPwjvDBQ3Sn5KxeY8TFXjg7EmixphOhC
l3g5rekga3vvM9A+Wsg4PpGGWVabwavopu1kT4IBRfXzRHTyIT29C83DjfG6Yyvl
UYg53Zv1zOnhK0qjHLKHLCU4UJflIDRLi6tiMQpk5u5WXFZ4on4U1Femq8DeLnan
sn3e/ikh6V9XpvhG2OoL
=j2XG
-END PGP SIGNATURE-
___
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: Removing documentation

[Jim Ohlstein]

Hello,

On 2/11/16 7:22 PM, Royce Williams wrote:

On Thu, Feb 11, 2016 at 11:17 AM, John Marino  wrote:

On 2/11/2016 9:08 PM, Royce Williams wrote:

On Thu, Feb 11, 2016 at 10:33 AM, John Marino  wrote:


On 2/11/2016 8:25 PM, Lev Serebryakov wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 07.02.2016 17:28, John Marino wrote:


ports-mgmt/synth.  I would love to hear what signficant thing
portmaster can do that Synth can't.  (honestly)

  Be installed FROM PORTS without all this build-one-more-gcc stuff.
Ada? For *port*management* tool? Are you joking?


Let me guess.  You've spent actually 0.0 nanoseconds preparing on the
subject before providing this enlightened take for the list.



Having read the entire thread, separate from the relative merits of
Synth, the core of Lev's incredulity isn't that off the mark.

On the face of it, Synth requiring ncurses seems reasonable ... but
its Ada dependency is a bit of a mild POLA violation.

Don't get me wrong -- I actually think Ada is pretty cool, and Lev
could have been nicer about it ;), but he's essentially right.

People's instincts are that software management is core functionality,
and should have few unusual dependencies.

My earlier side-thread point stands.  FreeBSD software management is
fragmented.  Until that is resolved, a lot of time and effort will be
wasted treating the symptoms.


Actually, you missed the fact that synth (nor poudriere) doesnt
re-invent anything.  Both are tightly integrated with pkg(8). You spoke
of both as if they were similar to portupgrade.

The "wrapper situation" that you proposed is already here.  So the whole
"fragmented" thing is not really true.


Is the abstraction is happening at the equivalent level here? The
platforms that I'm thinking of -- that appear to have already solved
this entire class of problem long ago -- feature wrappers around
apt-get, not wrappers around dpkg.

I'm advocating that we stop quasi-providing four different flavors of
apt-get.  Until there is a single and official mechanism for both
dependency resolution and configuration option management, the
fragmentation remains.


Sadly, I also use dpkg-based systems, not my first choice, but because 
sometimes they're the best currently available tool for the job at hand. 
I'd need about thirty hands to use my fingers to count how many times 
apt-get has left me with a broken package system, though aptitude 
usually is able to fix that. Most often that has happened after adding a 
third party repo (it happened recently with using MariDB's own repo 
instead of the official package) or when compiling from source and 
trying to delete unnecessary cruft. The biggest drawback to those 
systems is that compiling software and registering it can be a pain in 
the ass. The second biggest problem is those systems (Debian and Ubuntu 
specifically) are built around users who are totally willing to have the 
developers choose which options will be compiled in to "official" and 
"non-official" repos. That is, people who compile their own binaries are 
really an afterthought in the Debian and Ubuntu world. Some might call 
that a strength, and yes, dpkg is a nice system for people who want that 
kind of thing. It's made Debian based systems very popular, no doubt 
about it.


FreeBSD is different in that regard. The ports system is one of the 
things that makes it great. Being able to choose whether to compile 
everything, compile some ports and use official packages (or 
non-official repos) for others, or entirely to use pre-built binaries is 
one of the great strengths of FreeBSD and is one of the features that 
distinguishes it from most flavors of GNU/Linux. There are even tools 
for creating repos fairly easily. Have you ever tried to write a spec 
file for an RPM based distro? Ugh! Unfortunately, dpkg is not designed 
for people in those first two categories above. It can be made to work, 
but requires much more effort. Add in systemd and the nightmare continues...


This discussion is aimed at people who prefer to compile at least some 
of their own binaries, else they wouldn't need Portmaster or Synth or 
poudriere or portupgrade. Really and truly, and with due respect, 
speaking about dpkg is really a diversion, unintentional as it may be, 
and detracts from your main point about a totally unified package/ports 
system, which you believe belongs in base. I don't entirely disagree 
with that, but having choices about what wraps around pkg(8) should be 
up to the user. I use poudriere. For my purposes it's the best available 
tool. Even if you have half a dozen jails on one box poudriere + pkg 
makes distributing binaries to those jails a joy. Synth might do the 
same. Portmaster might be satisfactory for building a small number of 
ports in a system that mostly uses official packages. Portupgrade, if 
you can live with the ruby dependency and the occasional risk that it 
will crap out when upgrading 

Re: Removing documentation

[Michelle Sullivan]

Royce Williams wrote:
> On Fri, Feb 12, 2016 at 5:56 AM, Jim Ohlstein  wrote:
>
>
>   
>> FreeBSD is different in that regard. The ports system is one of the things
>> that makes it great. Being able to choose whether to compile everything,
>> compile some ports and use official packages (or non-official repos) for
>> others, or entirely to use pre-built binaries is one of the great strengths
>> of FreeBSD and is one of the features that distinguishes it from most
>> flavors of GNU/Linux. There are even tools for creating repos fairly easily.
>> Have you ever tried to write a spec file for an RPM based distro? Ugh!
>> Unfortunately, dpkg is not designed for people in those first two categories
>> above. It can be made to work, but requires much more effort. Add in systemd
>> and the nightmare continues...
>> 
>
> Interestingly, my experience -- after having been an admin for 70+
> FreeBSD boxes for a 50K+ ISP user base for 12 years -- is different.
>
> It is the apt-get system that has never failed me, and it is FreeBSD
> that has regularly left me with a software installation so wrecked
> that I had to deinstall every third party package and start over, or
> spending hours scripting a search-and-destroy mission to clean up the
> mess.  When people with significant FreeBSD experience regularly
> recommend the "nuke it from orbit" remedy regularly to people in the
> forums, that's a sign that something is deeply wrong.
>   

And from my experience of building and running SORBS over the last 13-14
years on Linux and FreeBSD...

Linux:

rpms (centos) - every system that used them ended up being replaced
because of horrible dependency loops.
dpkg (debian) - every couple of years something needs to be upgraded and
the OS has to be nuked from orbit (9 out of 10 libc patch)
tgz (slackware) - everything compiled from source management was a
nightmare but *never* resulted in unbootable systems... dependency -
well you had to manage that yourself.

FreeBSD:

source upgrade (OS): only failed at 5.x and that was bad.
freebsd-update (OS): several failures - particularly 9.x, particularly
around 9.3-p5 and 9.0->9.3 (in one jump)
ports (pre-pkg) from source: mostly worked fine - problems with options
changing and defaults changing.
ports (post pkg) from source: exactly the same problems as pre-pkg plus
occasionally the DB would get corrupted and then you have to nuke the
entire package system from orbit and reinstall all the ports.
ports (pre-pkg) from precompiled: finding the right version for the
system was always the issue because it was generally a moving target
about what was on the system and what was not.
ports (post-pkg) from precompiled: pretty much nuke and reinstall
everything everytime to be 100% sure it's all done which pkg makes
trivial... except when the DB blows up... which is when you need to have
a list of your ports that you need on the system...

Note: I don't use pkg at all anymore, don't even bother testing, gave up
on that when it nuked a remote system and left me unable to get in...
which resulted in an OS reload (from late 8.x IPMI remote consoles don't
work so when pkg nukes the sudo install and you have only allowed ssh
logins as a user (not root) - which is the FreeBSD default... well
rather than spreading FreeBSD in the company (to 1000's of machines) we
(others in the company) are now looking at the alternative and replacing
the 50+ SORBS ones... Congrats guys!)

> My Linux/dpkg/apt-get experience is entirely different.  I have pushed
> dpkg-based systems through three major OS/ABI upgrades with one or two
> commands, almost without having to perform any manual steps at all --
> and when I did, someone had captured them as part of the package
> system, informed me about it up front in the release notes, and almost
> always empowered me to run a simple package command to do what needed
> to be done automatically.  To be clear, this is not "hey, the default
> version of perl has changed, please do one of these five things, and
> if they don't work, delete everything and start over"
> /usr/ports/UPDATING equivalent.  These were genuinely deep things that
> justifiably required a human to decide which way they wanted to go.
> And there was no ambiguity in the official documentation about which
> commands I needed to run -- because there was a single, official
> method included in the base OS.
>
> Managing software across FreeBSD OS upgrades, by contrast, is replete
> with manual software removal and reinstallation steps, hunting down
> old library dependencies, etc.  Recurring "nuke it from orbit"
> debacles, coupled with the necessity of /usr/ports/UPDATING, makes the
> ports system an order of magnitude less reliable than stock
> Debian/Ubuntu ports.  This upgrade/management friction makes me far
> less likely to want to try to upgrade a FreeBSD system, which, in
> turn, when faced with a new install of some kind, makes me far more
> likely to use and recommend Ubuntu 

Re: Removing documentation

[Matthew Seaman]

On 2016/02/12 16:03, William A. Mahaffey III wrote:
> There was a thread a month or 2 back that mentioned adopting the pkg
> 'package format' for binary base packages. This would at least unify
> base & userland binaries under 1 package management system (& I *love*
> freebsd-update, BTW, *NO* aspersions being cast here). As I understand
> things, there would be separate repo's for base (obviously) & userland,
> but 1 unified format/package-manager. For those wanting to compile
> either base or userland themselves, they still could, since pkg is
> reasonably 'port' aware (& hopefuly could be made /usr/src aware as
> well), & they could use whatever src-base/port management tools they
> wanted. I definitely agree that a well integrated ability to possibly
> mix locally compiled stuff w/ repo-binaries is quite desirable in many
> scenarios & a nice advantage for FreeBSD. $0.02 from the (*very*) cheap
> seats, no more, no less 

Yes, this is planned for FreeBSD 11.0-RELEASE.  One big chunk of
functionality made possible by this change is the ability to selectively
install (or not) different bits of the base system -- so you could
install FreeBSD /without/ sendmail using the standard binary packages,
and maintain it entirely by binary pkg updates.  At the moment, if you
want a system 'WITHOUT_SENDMAIL' then you have to compile it yourself.

Cheers,

Matthew





signature.asc
Description: OpenPGP digital signature

Re: Removing documentation

[Michelle Sullivan]

William A. Mahaffey III wrote:
>
> There was a thread a month or 2 back that mentioned adopting the pkg
> 'package format' for binary base packages.

Yeah that would be the final nail..

...and then we have an OS that relies on an sqlite db to be patched up
correctly... why not go with BerkeleyDB .. oh wait, nevermind... how
about going the whole hog and putting in a registry...that'll work,
somewhere to store those pesky DWORDs so you could move rc.conf there as
well... oh and the registry of installed ports there as well...

No further comment necessary.

-- 
Michelle Sullivan
http://www.mhix.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: ports/pkg/OS integration 2.0 (was: Re: Removing documentation)

[Jim Ohlstein]

Hello,

On 2/12/16 11:25 AM, Royce Williams wrote:

On Fri, Feb 12, 2016 at 6:38 AM, Royce Williams  wrote:

This is, indeed, a gap in the Debian world.  It's one that the ports
system is a great start towards resolving.  That's why I think that
ports + pkg could be a superior offering that people would flock to,
and which deserves more focus.


To be fair, this is also why my comparison FreeBSD's ports system to
some other OSes binary package system is an unfair comparison.  :)
The complexity of letting people pick their own compilation options is
significant, and one that the Linux/Debian/dpkg world largely
sidesteps.

But it's exactly where I think that FreeBSD could really shine.
FreeBSD's ports system is the best system I've seen for managing
custom compilation.  If the OS, binary packages, and ports were more
tightly integrated, it would be magic.

Some goals:

* The OS needs a structured way to know that a different package has
changed its default behavior in some way.  (The Ubuntu
/etc/alternatives symlink system and other mechanisms solve this
well). In other words, a common framework that could accommodate
things like deciding to use a port or package instead of the facility
provided by the OS.


This is true. That probably would not be impossible to implement. It 
would be nice to be able to have two or more versions of a tool 
installed and relatively seamlessly switchable, at least for testing. 
I'm thinking PHP, Apache, nginx, etc.


/usr/local/bin/php5  and /usrlocal/bin/php7 with one at any time 
symlinked to /usr/local/bin/php or /usr/local/alternatives/php or whatever.




* Port maintainers should be able to express how one-offs and
conflicts should be resolved in a machine-readable way. (In other
words, as a test of fitness to purpose, most historic entries in
/usr/ports/UPDATING should be programmatically expressible in the
system).


Yes!



* The ports system needs to know which compilation options were used
by packages in the pkg system, so that if a conflict arises, it can be
intelligently expressed by the maintainers (or the user can be told
that they are mutually exclusive).


I believe at this time all official packages are compiled with the 
particular port's default options. That is until "flavors" are 
implemented at some point in the future.




* if the user's port configuration options aren't different from the
package defaults, ask the user if they want to use the package instead
(with global and per-port knobs to stop asking if the user desires).


Another big YES!



In other words, the end goal should be that the OS, ports, and
packages can coexist for common use cases.



--
Jim Ohlstein


"Never argue with a fool, onlookers may not be able to tell the 
difference." - Mark Twain

___
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: Removing documentation

[William A. Mahaffey III]

On 02/12/16 09:42, Matthew Seaman wrote:

On 12/02/2016 14:56, Jim Ohlstein wrote:

This is a good point. I still don't understand why pkg(8) is not in the
base (though I imagine there's a reason and it takes less than a minute
to install). There can't be many users who install a base system and use
it without a single additional piece of software. However, for my $0.02,
that is the only change I'd make to base at this point with respect to
package management, aside from my pkg(8) wishlist. As an aside, and
fwiw, unless there is a non-GPL'd Ada compiler out there, we won't see
Ada or any Ada-based binaries in base, even if Synth turns out to be the
best thing since sliced bread.

The primary reason pkg(8) is not in base is to decouple it from the
FreeBSD release timescale.  Given the promises about API/ABI stability
over a major release branch, development of pkg(8) would be forced to
slow to a crawl.

pkg(8) still has a lot of changes yet to be realized, both in its own
code, and in the code of both the ports and the base system, and in
adjunct software like poudriere or indeed, synth, so it is likely to
remain a 'port' for some time to come.  It is not completely
inconceivable though that at some future point, pkg(8) will have matured
into stability and require little further development, in which case,
importing it to base would be a natural next move.

Cheers,

Matthew



There was a thread a month or 2 back that mentioned adopting the pkg 
'package format' for binary base packages. This would at least unify 
base & userland binaries under 1 package management system (& I *love* 
freebsd-update, BTW, *NO* aspersions being cast here). As I understand 
things, there would be separate repo's for base (obviously) & userland, 
but 1 unified format/package-manager. For those wanting to compile 
either base or userland themselves, they still could, since pkg is 
reasonably 'port' aware (& hopefuly could be made /usr/src aware as 
well), & they could use whatever src-base/port management tools they 
wanted. I definitely agree that a well integrated ability to possibly 
mix locally compiled stuff w/ repo-binaries is quite desirable in many 
scenarios & a nice advantage for FreeBSD. $0.02 from the (*very*) cheap 
seats, no more, no less 



--

William A. Mahaffey III

 --

"The M1 Garand is without doubt the finest implement of war
 ever devised by man."
   -- Gen. George S. Patton Jr.

___
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: Removing documentation

[Matthew Seaman]

On 12/02/2016 14:56, Jim Ohlstein wrote:
> This is a good point. I still don't understand why pkg(8) is not in the
> base (though I imagine there's a reason and it takes less than a minute
> to install). There can't be many users who install a base system and use
> it without a single additional piece of software. However, for my $0.02,
> that is the only change I'd make to base at this point with respect to
> package management, aside from my pkg(8) wishlist. As an aside, and
> fwiw, unless there is a non-GPL'd Ada compiler out there, we won't see
> Ada or any Ada-based binaries in base, even if Synth turns out to be the
> best thing since sliced bread.

The primary reason pkg(8) is not in base is to decouple it from the
FreeBSD release timescale.  Given the promises about API/ABI stability
over a major release branch, development of pkg(8) would be forced to
slow to a crawl.

pkg(8) still has a lot of changes yet to be realized, both in its own
code, and in the code of both the ports and the base system, and in
adjunct software like poudriere or indeed, synth, so it is likely to
remain a 'port' for some time to come.  It is not completely
inconceivable though that at some future point, pkg(8) will have matured
into stability and require little further development, in which case,
importing it to base would be a natural next move.

Cheers,

Matthew




signature.asc
Description: OpenPGP digital signature

Re: Removing documentation

[Royce Williams]

On Fri, Feb 12, 2016 at 5:56 AM, Jim Ohlstein  wrote:

> On 2/11/16 7:22 PM, Royce Williams wrote:

>> Is the abstraction is happening at the equivalent level here? The
>> platforms that I'm thinking of -- that appear to have already solved
>> this entire class of problem long ago -- feature wrappers around
>> apt-get, not wrappers around dpkg.
>>
>> I'm advocating that we stop quasi-providing four different flavors of
>> apt-get.  Until there is a single and official mechanism for both
>> dependency resolution and configuration option management, the
>> fragmentation remains.
>
> Sadly, I also use dpkg-based systems, not my first choice, but because
> sometimes they're the best currently available tool for the job at hand. I'd
> need about thirty hands to use my fingers to count how many times apt-get
> has left me with a broken package system, though aptitude usually is able to
> fix that. Most often that has happened after adding a third party repo (it
> happened recently with using MariDB's own repo instead of the official
> package) or when compiling from source and trying to delete unnecessary
> cruft. The biggest drawback to those systems is that compiling software and
> registering it can be a pain in the ass. The second biggest problem is those
> systems (Debian and Ubuntu specifically) are built around users who are
> totally willing to have the developers choose which options will be compiled
> in to "official" and "non-official" repos. That is, people who compile their
> own binaries are really an afterthought in the Debian and Ubuntu world. Some
> might call that a strength, and yes, dpkg is a nice system for people who
> want that kind of thing. It's made Debian based systems very popular, no
> doubt about it.

Third-party repos are an entirely other kettle of fish, I think.  At
that point, you're throwing yourself on the mercy of uncoordinated
third-party dependency information that conflicts with the official
one, and the dpkg/apt-get system should not be held responsible for
that.

> FreeBSD is different in that regard. The ports system is one of the things
> that makes it great. Being able to choose whether to compile everything,
> compile some ports and use official packages (or non-official repos) for
> others, or entirely to use pre-built binaries is one of the great strengths
> of FreeBSD and is one of the features that distinguishes it from most
> flavors of GNU/Linux. There are even tools for creating repos fairly easily.
> Have you ever tried to write a spec file for an RPM based distro? Ugh!
> Unfortunately, dpkg is not designed for people in those first two categories
> above. It can be made to work, but requires much more effort. Add in systemd
> and the nightmare continues...

Interestingly, my experience -- after having been an admin for 70+
FreeBSD boxes for a 50K+ ISP user base for 12 years -- is different.

It is the apt-get system that has never failed me, and it is FreeBSD
that has regularly left me with a software installation so wrecked
that I had to deinstall every third party package and start over, or
spending hours scripting a search-and-destroy mission to clean up the
mess.  When people with significant FreeBSD experience regularly
recommend the "nuke it from orbit" remedy regularly to people in the
forums, that's a sign that something is deeply wrong.

My Linux/dpkg/apt-get experience is entirely different.  I have pushed
dpkg-based systems through three major OS/ABI upgrades with one or two
commands, almost without having to perform any manual steps at all --
and when I did, someone had captured them as part of the package
system, informed me about it up front in the release notes, and almost
always empowered me to run a simple package command to do what needed
to be done automatically.  To be clear, this is not "hey, the default
version of perl has changed, please do one of these five things, and
if they don't work, delete everything and start over"
/usr/ports/UPDATING equivalent.  These were genuinely deep things that
justifiably required a human to decide which way they wanted to go.
And there was no ambiguity in the official documentation about which
commands I needed to run -- because there was a single, official
method included in the base OS.

Managing software across FreeBSD OS upgrades, by contrast, is replete
with manual software removal and reinstallation steps, hunting down
old library dependencies, etc.  Recurring "nuke it from orbit"
debacles, coupled with the necessity of /usr/ports/UPDATING, makes the
ports system an order of magnitude less reliable than stock
Debian/Ubuntu ports.  This upgrade/management friction makes me far
less likely to want to try to upgrade a FreeBSD system, which, in
turn, when faced with a new install of some kind, makes me far more
likely to use and recommend Ubuntu server over FreeBSD.  This pains me
greatly, as I have been a FreeBSD advocate/fan for fifteen years, and
I believe that FreeBSD's tightly 

Re: Removing documentation

[Kurt Jaeger]

Hi!

Michelle wrote:
> ports (post pkg) from source: exactly the same problems as pre-pkg plus
> occasionally the DB would get corrupted and then you have to nuke the
> entire package system from orbit and reinstall all the ports.

Interestingly, I had my cases of strange dependencies chains, but
I can't remember a case where the pkg-db was really trashed to no
longer function.

The more recent pkg versions are very robust for my use cases.

-- 
p...@opsec.eu+49 171 3101372 4 years to go !
___
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: ports/pkg/OS integration 2.0 (was: Re: Removing documentation)

[Roger Marquis]

(The Ubuntu /etc/alternatives symlink system and other mechanisms solve
this well)


That hasn't been my experience but then I'm not a big fan of symlinks
which can't be safely modified outside of the (d)pkg system.  As a
general rule you want to avoid such unnecessary layers of abstraction
where possible.


* if the user's port configuration options aren't different from the
package defaults, ask the user if they want to use the package instead
(with global and per-port knobs to stop asking if the user desires).


Can't really see much use for this.  Those of us building from source
know when we can install a binary and nobody really wants to be
held-up by another prompt.

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: ports/pkg/OS integration 2.0 (was: Re: Removing documentation)

[Royce Williams]

On Fri, Feb 12, 2016 at 1:07 PM, Roger Marquis  wrote:
>>> (The Ubuntu /etc/alternatives symlink system and other mechanisms solve
>>> this well)
>
>
> That hasn't been my experience but then I'm not a big fan of symlinks
> which can't be safely modified outside of the (d)pkg system.  As a
> general rule you want to avoid such unnecessary layers of abstraction
> where possible.
>
>>> * if the user's port configuration options aren't different from the
>>> package defaults, ask the user if they want to use the package instead
>>> (with global and per-port knobs to stop asking if the user desires).
>
>
> Can't really see much use for this.  Those of us building from source
> know when we can install a binary and nobody really wants to be
> held-up by another prompt.

That's exactly why I suggested the knobs.

I regularly run into circumstances where I want to tweak a config
option for one port, but I'd actually prefer that its dependencies be
packages ... until I need to tweak something else.

So in my pie-in-the-sky world, when an upgrade triggers the need to
upgrade a dependency, if the config options haven't changed, then
install the package automatically; otherwise, show me the new config
options (highlighted!), and ask me if I want to change the defaults.
If I do, that dependency becomes managed from ports.  If I don't, it
stays managed by packages.

The knobs would let you make this behavior possible -- or not.

It would be nice to be asked at the point of installing the system
what kind of software management you want:

[X] Install software from binary packages only
[ ] Install software from ports only (compiling everything locally)
[ ] Prefer packages, prompting me when default options change
[ ] Prefer ports, but use packages if the port options are identical

Royce
___
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: Removing documentation

[Royce Williams]

On Thu, Feb 11, 2016 at 3:41 PM, John Marino  wrote:
>
> On 2/12/2016 1:22 AM, Royce Williams wrote:
> > Is the abstraction is happening at the equivalent level here? The
> > platforms that I'm thinking of -- that appear to have already solved
> > this entire class of problem long ago -- feature wrappers around
> > apt-get, not wrappers around dpkg.
>
> I'm not a linux guy so those things don't mean much the me.  The
> abstraction layer here is at the appropriate level.  I'm not seeing this
> fragmentation problem you're talking about, at least not with the newer
> tools.


It's the long tail of non-newer tools that appears to be a big part of
the problem.  I think that you and I are in agreement there.  But I
also think that the older tools do some things well that enough people
will miss that it will undermine adoption of newer tools for a while.

>
> > I'm advocating that we stop quasi-providing four different flavors of
> > apt-get.  Until there is a single and official mechanism for both
> > dependency resolution and configuration option management, the
> > fragmentation remains.
>
> Why do you think this is the case?  Ports defines the dependencies and
> pkg respects them.  I'm not seeing where there more than one method
> here.  What other ones are there?


The current ports/pkg relationship is still fragile, perhaps because
it's new.  I almost abandoned FreeBSD entirely a couple of months ago
when an interesting corner case of the use of pkg managed to
unilaterally and without warning delete in its entirety the contents
of /usr/local/etc/rc.d in of my jails.

Contrast this with the Ubuntu world, where there is a well-baked
"unattended-upgrades" option that automatically downloads and upgrades
all security updates for both the OS and all third-party packages.

>
> > If there were no ports system, and everything was package-driven, I'd
> > agree.  Synth and its cousins exist because people work from ports --
> > which means that dependencies matter.
>
> Synth exist because people are insisting to build from source (even
> irrationally) so they might as well do it correctly.  The statement
> above doesn't have anything to do with Synth being a binary.


If you believe that people who want to build from source are
irrational, to me this means that you do not yet understand the
current use cases of the software you're purporting to replace.

>
> If a shell script was so good, why is portmaster unmaintainable?


I wasn't advocating for using a shell script.  I'm advocating for a
core-driven, Foundation-funded initiative to identify requirements and
functionality for true, integrated ports and packages management,
drive it to completion for parity with modern package management
practices, and bring it into core.

>
> > The laissez-faire "there's no requirement to build from ports" that
> > permeates FreeBSD is exactly what's wrong.  The fact that half of the
> > documentation and quasi-official tools tell people "hey, use one of
> > these three ports management tools, or maybe packages, pick what works
> > for you -- oh, and be sure to check /usr/ports/UPDATING every time you
> > touch any port or package" is a deep symptom of this fragmentation.
>
> THERE'S NO REQUIREMENT THAT SOMETHING THAT BUILDS PORTS NEEDS THAT
> ITSELF IS BUILT FROM PORTS.  You responded to something different.


Breathe. :)

I'm not saying it's required.  I'm saying that it's what many people
do -- and probably for reasons that should be identified and
understood before dismissing them.

> > Because FreeBSD software management itself is not purely package based.
> >
> > As long as the ports system exists (and I think it should!), the
> > management of compilation requirements -- especially for something
> > that might need to be bootstrapped early, like a software management
> > tool -- is a valid topic.
>
> Well, except *this* tool will never be in a "bootstrap" path.  Above is
> completely irrelevant.  Besides, if the base is built, ports work,
> period.  There are no "compilation" requirements.
>
>
> > To be clear: except for the Ada/ruby/whatever dependency chain, my
> > beef isn't with Synth qua Synth.  It's that every time we spin up Yet
> > Another Optional Software Management Tool, we fragment further.  If
> > Synth becomes the holy grail of package management -- so compelling
> > that it becomes the only choice people would want to make, which is
> > what I think we need -- then it should become part of base.
>
> 1) you should focus on retiring the old tools


No disagreement there.

>
> 2) It will never be part of base


That's where we differ. I think that a software management suite that
has fully identified the use cases would necessarily need to be part
of base.  And the fact that it's not part of base is only going to
make the fragmentation worse over time.  Mine is just one opinion, of
course.

>
> 3) no ports tool has even been part of base


I know. I think that's bad.

>
> 4) the "winner" 

Re: Removing documentation

[William A. Mahaffey III]

On 02/11/16 14:15, Royce Williams wrote:

On Thu, Feb 11, 2016 at 10:33 AM, John Marino  wrote:

On 2/11/2016 8:25 PM, Lev Serebryakov wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 07.02.2016 17:28, John Marino wrote:


ports-mgmt/synth.  I would love to hear what signficant thing
portmaster can do that Synth can't.  (honestly)

  Be installed FROM PORTS without all this build-one-more-gcc stuff.
Ada? For *port*management* tool? Are you joking?

Let me guess.  You've spent actually 0.0 nanoseconds preparing on the
subject before providing this enlightened take for the list.


Having read the entire thread, separate from the relative merits of
Synth, the core of Lev's incredulity isn't that off the mark.

On the face of it, Synth requiring ncurses seems reasonable ... but
its Ada dependency is a bit of a mild POLA violation.

Don't get me wrong -- I actually think Ada is pretty cool, and Lev
could have been nicer about it ;), but he's essentially right.

People's instincts are that software management is core functionality,
and should have few unusual dependencies.

My earlier side-thread point stands.  FreeBSD software management is
fragmented.  Until that is resolved, a lot of time and effort will be
wasted treating the symptoms.

Royce



Preach it *LOUD*, brother :-)  (fragmented package management)


For my , that is about *all* RH & Debian have going for them, but 
yum/RPM et al cover up a multitude of other sins 



--

William A. Mahaffey III

 --

"The M1 Garand is without doubt the finest implement of war
 ever devised by man."
   -- Gen. George S. Patton Jr.

___
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: Removing documentation

[John Marino]

On 2/11/2016 8:25 PM, Lev Serebryakov wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
> 
> On 07.02.2016 17:28, John Marino wrote:
> 
>> ports-mgmt/synth.  I would love to hear what signficant thing
>> portmaster can do that Synth can't.  (honestly)
>  Be installed FROM PORTS without all this build-one-more-gcc stuff.
> Ada? For *port*management* tool? Are you joking?

Let me guess.  You've spent actually 0.0 nanoseconds preparing on the
subject before providing this enlightened take for the list.
___
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: Removing documentation

[John Marino]

On 2/11/2016 9:08 PM, Royce Williams wrote:
> On Thu, Feb 11, 2016 at 10:33 AM, John Marino  wrote:
>>
>> On 2/11/2016 8:25 PM, Lev Serebryakov wrote:
>>> -BEGIN PGP SIGNED MESSAGE-
>>> Hash: SHA512
>>>
>>> On 07.02.2016 17:28, John Marino wrote:
>>>
 ports-mgmt/synth.  I would love to hear what signficant thing
 portmaster can do that Synth can't.  (honestly)
>>>  Be installed FROM PORTS without all this build-one-more-gcc stuff.
>>> Ada? For *port*management* tool? Are you joking?
>>
>> Let me guess.  You've spent actually 0.0 nanoseconds preparing on the
>> subject before providing this enlightened take for the list.
> 
> 
> Having read the entire thread, separate from the relative merits of
> Synth, the core of Lev's incredulity isn't that off the mark.
> 
> On the face of it, Synth requiring ncurses seems reasonable ... but
> its Ada dependency is a bit of a mild POLA violation.
> 
> Don't get me wrong -- I actually think Ada is pretty cool, and Lev
> could have been nicer about it ;), but he's essentially right.
> 
> People's instincts are that software management is core functionality,
> and should have few unusual dependencies.
> 
> My earlier side-thread point stands.  FreeBSD software management is
> fragmented.  Until that is resolved, a lot of time and effort will be
> wasted treating the symptoms.

Actually, you missed the fact that synth (nor poudriere) doesnt
re-invent anything.  Both are tightly integrated with pkg(8). You spoke
of both as if they were similar to portupgrade.

The "wrapper situation" that you proposed is already here.  So the whole
"fragmented" thing is not really true.

Synth is a binary.  There's no POLA there.
There's no requirement to build from ports, that's an unsubstanciated
invention.  Notice that not a single person could defend that position
after a challenge.  There's no technical basis for it; it's just emotional.

In a straight fly-off against any of the tools, Synth wins hands down
with any objective measurement.  Poudriere is slightly more bulletproof
and more appropriate for a cluster (as it was targetted at) but for
average user Synth is better suited.

It's a concurrent builder.  Ada is a concurrent language.  How is its
suitability even a debate?

John
___
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: Removing documentation

[Royce Williams]

On Thu, Feb 11, 2016 at 10:33 AM, John Marino  wrote:
>
> On 2/11/2016 8:25 PM, Lev Serebryakov wrote:
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA512
> >
> > On 07.02.2016 17:28, John Marino wrote:
> >
> >> ports-mgmt/synth.  I would love to hear what signficant thing
> >> portmaster can do that Synth can't.  (honestly)
> >  Be installed FROM PORTS without all this build-one-more-gcc stuff.
> > Ada? For *port*management* tool? Are you joking?
>
> Let me guess.  You've spent actually 0.0 nanoseconds preparing on the
> subject before providing this enlightened take for the list.


Having read the entire thread, separate from the relative merits of
Synth, the core of Lev's incredulity isn't that off the mark.

On the face of it, Synth requiring ncurses seems reasonable ... but
its Ada dependency is a bit of a mild POLA violation.

Don't get me wrong -- I actually think Ada is pretty cool, and Lev
could have been nicer about it ;), but he's essentially right.

People's instincts are that software management is core functionality,
and should have few unusual dependencies.

My earlier side-thread point stands.  FreeBSD software management is
fragmented.  Until that is resolved, a lot of time and effort will be
wasted treating the symptoms.

Royce
___
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: Removing documentation (was: [Bug 206922] Handbook: Chapter 4.5+ changes)

[Lev Serebryakov]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 07.02.2016 17:28, John Marino wrote:

> ports-mgmt/synth.  I would love to hear what signficant thing
> portmaster can do that Synth can't.  (honestly)
 Be installed FROM PORTS without all this build-one-more-gcc stuff.
Ada? For *port*management* tool? Are you joking?

- -- 
// Lev Serebryakov
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQJ8BAEBCgBmBQJWvOAdXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRGOTZEMUNBMEI1RjQzMThCNjc0QjMzMEFF
QUIwM0M1OEJGREM0NzhGAAoJEOqwPFi/3EePG38P/2y6BiUF0XgBmPPq0KE+Vfui
fFeszBcYZ9AfPD92jKXMbvMsMoY93WZRQB69TmQ4c7zXZLQvSvoT9CSjMMzdzOfq
UHVuiEpsCz2q4knwij5G9W5IGomxgT9tc/g26tameuZVu8ududFLNCcofX8zS6pb
pFLoUTKkALmAJOwyxtMOwtrSGeZXrbq1C6FpXFOXuO7aMcmLA5qDicqdZSNhBDWG
27jjECGM0RyPMChA6OMjYqvzyP6Y3TjAfnxy9PI8S8jXY/oXKVebdRpl27VqRaYw
A5gelEb45BGaxF77b35ZTd8gObesoW9i30KmoEEmDTyAwaRjfce8g7WRmvJpNQEy
BcYaJYDDtT/oSbLh/XqMNPCmRbNlSaQId4QJmlzpPlbwVHlBtw3EKZS6PVRQG30U
Nn40YEiLqhy6uL33VENmsQlRJxnlhOICP24mQUfiWoIYjww91QEL3CCIQilL79rN
FarIAv+SVNld+2AnT+Q1WnqrYX5DNSyhIbjm7VpB1GGBnSGXCjeHvkYGl4JAl9H+
4xm3otpZLU6SsdePSgqJ8fSd0iKygHNixrzYYv+o6DuDEC2JU//G7994r5xM3KXO
+CTXd/KlruyK4eIJ32gTcU+nQ21hzlMfgviTLgEKOJplfVWDZ92aFpJaXOnKj4OP
LuFstIC8L6cEjxh8Fm5m
=JBt1
-END PGP SIGNATURE-
___
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: Removing documentation

[Royce Williams]

On Thu, Feb 11, 2016 at 11:17 AM, John Marino  wrote:
> On 2/11/2016 9:08 PM, Royce Williams wrote:
>> On Thu, Feb 11, 2016 at 10:33 AM, John Marino  wrote:
>>>
>>> On 2/11/2016 8:25 PM, Lev Serebryakov wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA512

 On 07.02.2016 17:28, John Marino wrote:

> ports-mgmt/synth.  I would love to hear what signficant thing
> portmaster can do that Synth can't.  (honestly)
  Be installed FROM PORTS without all this build-one-more-gcc stuff.
 Ada? For *port*management* tool? Are you joking?
>>>
>>> Let me guess.  You've spent actually 0.0 nanoseconds preparing on the
>>> subject before providing this enlightened take for the list.
>>
>>
>> Having read the entire thread, separate from the relative merits of
>> Synth, the core of Lev's incredulity isn't that off the mark.
>>
>> On the face of it, Synth requiring ncurses seems reasonable ... but
>> its Ada dependency is a bit of a mild POLA violation.
>>
>> Don't get me wrong -- I actually think Ada is pretty cool, and Lev
>> could have been nicer about it ;), but he's essentially right.
>>
>> People's instincts are that software management is core functionality,
>> and should have few unusual dependencies.
>>
>> My earlier side-thread point stands.  FreeBSD software management is
>> fragmented.  Until that is resolved, a lot of time and effort will be
>> wasted treating the symptoms.
>
> Actually, you missed the fact that synth (nor poudriere) doesnt
> re-invent anything.  Both are tightly integrated with pkg(8). You spoke
> of both as if they were similar to portupgrade.
>
> The "wrapper situation" that you proposed is already here.  So the whole
> "fragmented" thing is not really true.

Is the abstraction is happening at the equivalent level here? The
platforms that I'm thinking of -- that appear to have already solved
this entire class of problem long ago -- feature wrappers around
apt-get, not wrappers around dpkg.

I'm advocating that we stop quasi-providing four different flavors of
apt-get.  Until there is a single and official mechanism for both
dependency resolution and configuration option management, the
fragmentation remains.

> Synth is a binary.  There's no POLA there.

If there were no ports system, and everything was package-driven, I'd
agree.  Synth and its cousins exist because people work from ports --
which means that dependencies matter.

> There's no requirement to build from ports, that's an unsubstanciated
> invention.  Notice that not a single person could defend that position
> after a challenge.  There's no technical basis for it; it's just emotional.

The laissez-faire "there's no requirement to build from ports" that
permeates FreeBSD is exactly what's wrong.  The fact that half of the
documentation and quasi-official tools tell people "hey, use one of
these three ports management tools, or maybe packages, pick what works
for you -- oh, and be sure to check /usr/ports/UPDATING every time you
touch any port or package" is a deep symptom of this fragmentation.

> In a straight fly-off against any of the tools, Synth wins hands down
> with any objective measurement.  Poudriere is slightly more bulletproof
> and more appropriate for a cluster (as it was targetted at) but for
> average user Synth is better suited.
>
> It's a concurrent builder.  Ada is a concurrent language.  How is its
> suitability even a debate?

Because FreeBSD software management itself is not purely package based.

As long as the ports system exists (and I think it should!), the
management of compilation requirements -- especially for something
that might need to be bootstrapped early, like a software management
tool -- is a valid topic.

To be clear: except for the Ada/ruby/whatever dependency chain, my
beef isn't with Synth qua Synth.  It's that every time we spin up Yet
Another Optional Software Management Tool, we fragment further.  If
Synth becomes the holy grail of package management -- so compelling
that it becomes the only choice people would want to make, which is
what I think we need -- then it should become part of base.

If that happened, would we want to ship with Ada in base?  If not, why not?

Royce
___
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: Removing documentation

[John Marino]

On 2/12/2016 1:22 AM, Royce Williams wrote:
> Is the abstraction is happening at the equivalent level here? The
> platforms that I'm thinking of -- that appear to have already solved
> this entire class of problem long ago -- feature wrappers around
> apt-get, not wrappers around dpkg.

I'm not a linux guy so those things don't mean much the me.  The
abstraction layer here is at the appropriate level.  I'm not seeing this
fragmentation problem you're talking about, at least not with the newer
tools.


> I'm advocating that we stop quasi-providing four different flavors of
> apt-get.  Until there is a single and official mechanism for both
> dependency resolution and configuration option management, the
> fragmentation remains.

Why do you think this is the case?  Ports defines the dependencies and
pkg respects them.  I'm not seeing where there more than one method
here.  What other ones are there?

> If there were no ports system, and everything was package-driven, I'd
> agree.  Synth and its cousins exist because people work from ports --
> which means that dependencies matter.

Synth exist because people are insisting to build from source (even
irrationally) so they might as well do it correctly.  The statement
above doesn't have anything to do with Synth being a binary.

If a shell script was so good, why is portmaster unmaintainable?


> The laissez-faire "there's no requirement to build from ports" that
> permeates FreeBSD is exactly what's wrong.  The fact that half of the
> documentation and quasi-official tools tell people "hey, use one of
> these three ports management tools, or maybe packages, pick what works
> for you -- oh, and be sure to check /usr/ports/UPDATING every time you
> touch any port or package" is a deep symptom of this fragmentation.

THERE'S NO REQUIREMENT THAT SOMETHING THAT BUILDS PORTS NEEDS THAT
ITSELF IS BUILT FROM PORTS.  You responded to something different.



> Because FreeBSD software management itself is not purely package based.
> 
> As long as the ports system exists (and I think it should!), the
> management of compilation requirements -- especially for something
> that might need to be bootstrapped early, like a software management
> tool -- is a valid topic.

Well, except *this* tool will never be in a "bootstrap" path.  Above is
completely irrelevant.  Besides, if the base is built, ports work,
period.  There are no "compilation" requirements.


> To be clear: except for the Ada/ruby/whatever dependency chain, my
> beef isn't with Synth qua Synth.  It's that every time we spin up Yet
> Another Optional Software Management Tool, we fragment further.  If
> Synth becomes the holy grail of package management -- so compelling
> that it becomes the only choice people would want to make, which is
> what I think we need -- then it should become part of base.

1) you should focus on retiring the old tools
2) It will never be part of base
3) no ports tool has even been part of base
4) the "winner" will be determined by merit.  If some people insist on
using inferior/broken/obsolete/unmaintained tools it's their choice and
problem.  The majority will migrate naturally.

This started because I think that if a tool is documented in handbook,
it must be maintained (not part of base).  I've got no issue with
non-base software documented.  I was saying that being in the handbook
should have a required level of quality and abandoning it would cause
the quality to fall under that level.

John
___
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: Removing documentation (was: [Bug 206922] Handbook: Chapter 4.5+ changes)

[Matt Smith]

On Feb 11 22:25, Lev Serebryakov wrote:

On 07.02.2016 17:28, John Marino wrote:


ports-mgmt/synth.  I would love to hear what signficant thing
portmaster can do that Synth can't.  (honestly)

Be installed FROM PORTS without all this build-one-more-gcc stuff.
Ada? For *port*management* tool? Are you joking?

--
// Lev Serebryakov


Remember that before portmaster we had cvsup which was written in 
Modula-3 and portupgrade which is written in Ruby. Whilst it is nice 
that portmaster is just a simple shell script with no dependancies 
that's a relatively new thing.


--
Matt
___
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: Removing documentation

[John Marino]

On 2/11/2016 10:32 PM, Matt Smith wrote:
> Remember that before portmaster we had cvsup which was written in
> Modula-3 and portupgrade which is written in Ruby. Whilst it is nice
> that portmaster is just a simple shell script with no dependancies
> that's a relatively new thing.

I'm familiar with the M3 situation (I actual maintain the M3 port which
came in after CVS was removed) and I understand why people are gunshy
about obscure languages.

I don't think this is a comparable situation though.  A broken Synth
cannot leave the system in a bad or unrecoverable state.  One could
remove it and it's products in a second and the machines that used it
would continue as normal.  There are alternatives (ports, official
packages, poudriere, portmaster, etc) so there's no critical path.

I'm always aware (and was bitten by) portupgrade and ruby.  I know why
people wouldn't want that again.  Still the situation cannot be compared
to Synth.

Portmaster was good in that it didn't have its own database and used the
ports framework.  Poudriere also does that and now Synth, so it's no
longer unique in that aspect.

Dependencies matter if it's part of a bootstrap process or maybe part of
base or in a critical path, but I don't think any of that applies in
this case.

John
___
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: Removing documentation

[Guido Falsi]

On 02/10/16 12:21, John Marino wrote:
> On 2/9/2016 9:27 PM, John Marino wrote:
>> On 2/9/2016 9:20 PM, Warren Block wrote:
>>> On Tue, 9 Feb 2016, John Marino wrote:
>>>
 On 2/9/2016 7:20 PM, Warren Block wrote:
>> If you have the build log, I'd like to see it.  Dewayne G. got an error
>> after overriding CPUTYPE (do you do that too?) and I'm thinking it's
>> sensitive to CPU and I'd like to know more.
>
> Yes, I use
>
> CPUTYPE?=core-avx2

 What happens when you try to build lang/gcc6-devel ?
 Same issue or does it complete?
>>>
>>> It builds successfully, in about 40 minutes.
>>
>> My suspicion is that due to the bootstrap, we'd have two possible options:
>> A) turn on the full bootstrap which takes the same amount of time as
>> gcc6-devel does (I'm not sure it will work but there's a chance)
>> B) I put CPUTYPE=native in the gcc6-aux Makefile
>>
>> I am inclined towards B.  It works on DragonFly but I need somebody else
>> to test it on i7 on FreeBSD.  I asked Dewayne, but I'd be grateful if
>> you could test it as well.
> 
> Hi Warren,
> Dewayne got back to me, and it appears the only solution is to put
> "CPUTYPE=" in the gcc6-aux makefile.  I think the bootstrap compiler
> (the ada-capable compiler downloaded to build gcc6-aux) doesn't know
> these instructions and that's the issue.  The options are don't override
> CPUTYPE or regenerate the bootstrap, but that might have other
> consequences or won't fix every combination.

I just tried to compile lang/gcc in poudriere with CPUTYPE set and it
failed too in configure phase.

It appears that any setting "higher" than nocona makes the gcc ports
fail, not only gcc6.

-- 
Guido Falsi 
___
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: maintaining portmaster ? was: Re: Removing documentation

[Kurt Jaeger]

Hi!

> I'm asking myself how to manage the code. Should i create a new GitHub 
> repository? Fork the existing from freebsd/portmaster? How to handle the 
> LOCAL Master-Site?

Fork it on Github, for now. It can later be merged with freebsd/portmaster.

-- 
p...@opsec.eu+49 171 3101372 4 years to go !
___
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: Removing documentation

[Kevin Oberman]

On Mon, Feb 8, 2016 at 1:55 AM, John Marino  wrote:

> On 2/8/2016 10:30 AM, Mathias Picker wrote:
> > Am Montag, den 08.02.2016, 08:35 +0100 schrieb John Marino:
> > While I like the ideas of synth, and hoped I could use it to just build
> > my 3-8 ports with modified options, on first look I found many things
> > suggesting that it's not yet ready:
> >
> > - shows uninteresting eye candy instead of build
>
> Every single port has it's own build log with far more detail that a
> source build provides (similar to poudriere)
>
> > - stops at every conf file version mismatch requiring me to start make
> > config by hand, and then to re-run when it discovers the next mismatch.
> > I mean, WTF?
>
> This is incorrect.  It lists *ALL* the configuration mismatches at once.
>  This is actually a huge "pro" for synth; no other tool detects this
> mismatches.  It is far worse to have cached options that do not match
> the current port.  The port can be misbuilt and it's a major pain to
> troubleshoot.  All build tools should be doing this.  Are you really
> proposing that a tool build a port with a bad configuration file?  You
> should be thanking Synth for alerting to a problem you obviously didn't
> know you had.
>
> Also, once you fix it, then configuration problems are rare, they occur
> when the port changes.
>

OK. I have been playing with synth and I must say that I find it
impressive. Not that I am ready to put it into  "production", but
impressive, none the less. Maybe after a bit more testing and updating all
ports after moving from 10 to 11 (which will not be too soon). Still, it is
way better than poudriere for my limited purposes. I will certainly use it
for that, even if I still use portmaster for my "development" system.

The stale configuration file issue has me a bit confused. The man page does
not make it clear just what makes a config "stale". All of my ports are up
to date as of 11:00 UTC this morning. As far as I know, all of the configs
are "current", although the actual config run may have been for a much
older version. "synth status shows 46 cases. I looked at one
(sysutils/tmux) and the options listed by "make showconfig" are no
different from those in the current Makefile, so I don't understand why
they are stale.

I also have found at least one thing portmster can do that synth can't, but
I expect pkg can, so I won't complain about it until I have tried using pkg
to list all top-level ports (nothing depends on them) to use to re-install
all ports. I could list all ports, it's just that this is a much longer
list and portmaster did the job nicely with a simple example in the man
page.

And, please, everyone, let's stop with the silly statements like "the
Handbook should be limited to the base system" or "a maintainer needs to be
able to fix all PRs". At least one is a trivial annoyance in the display
only that is amazingly hard to fix. I asked Doug about it quite a while ago
and he said that he's keep beating on it, but a proper fix would
substantially complicate the script and be rather fragile, as well. I
assume that he is no longer beating on it.

> --
> 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: Removing documentation

[John Marino]

On 2/10/2016 11:31 PM, Alphons van Werven wrote:
> ???Between all the question marks (sorry, I just can't help myself) I
> can reveal that Portmaster detects at least some of the above kinds of
> changes. Perhaps not all four, but at least some (if not most).
> 
> I suspect it's probably not so much a matter of a feature having been
> removed, but rather of Portmaster insufficiently keeping up with the ports
> infrastructure in general and the options framework in particular. It's an
> orphaned port after all.

Well, if I make the assume that Kevin has been using portmaster, and
that using Synth revealed 42 obsolete cached configurations, I would
have to conclude PM doesn't do this anymore or does it very poorly and
misses a large number of configs.

John
___
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: Removing documentation

[Alphons van Werven]

John Marino wrote:

> Well, if I make the assume that Kevin has been using portmaster, and
> that using Synth revealed 42 obsolete cached configurations, I would
> have to conclude PM doesn't do this anymore or does it very poorly and
> misses a large number of configs.

Using the latest version of Portmaster, I feel confident in stating that
the "doesn't do this anymore" part appears to be false. My money is on
incomplete detection, i.e. detecting only a subset (but doing at least
that part correctly) of all possible kinds of option changes.

However, I did not intend to sidetrack the discussion. As previously
mentioned, it's just an observation.

Fonz

-- 
Get the cheese to sickbay. The doctor should look at it as soon as possible.
-- Lt. B'Elanna Torres


signature.asc
Description: PGP signature

Re: Removing documentation

[John Marino]

On 2/10/2016 10:15 PM, Kevin Oberman wrote:
> 
> The stale configuration file issue has me a bit confused. The man page
> does not make it clear just what makes a config "stale". All of my ports
> are up to date as of 11:00 UTC this morning. As far as I know, all of
> the configs are "current", although the actual config run may have been
> for a much older version. "synth status shows 46 cases. I looked at one
> (sysutils/tmux) and the options listed by "make showconfig" are no
> different from those in the current Makefile, so I don't understand why
> they are stale.

Stale isn't the right word.  You could use "invalid" or "obsolete"
instead.  The saved configuration does not match the current port.

Imagine a month ago you run "make config".  It saves the status of the 4
options on this imaginary port.  Now imagine any of the following
happening to the port.

A) An option is added
B) An option is removed
C) An option default changed.
D) Any other option configuration changed.

Now the month-old saved configuration doesn't match the port.  See the
problem?

Synth is the *only* tool that detects this.  The rest keep using the old
configuration the best they can, resulting in hard to track down bugs.
Removing the saved configuration solves the problem; then Synth uses the
defaults.  Running "make config" also solves the problem, the
configuration will match the port again.

 > I also have found at least one thing portmster can do that synth can't,
> but I expect pkg can, so I won't complain about it until I have tried
> using pkg to list all top-level ports (nothing depends on them) to use
> to re-install all ports. I could list all ports, it's just that this is
> a much longer list and portmaster did the job nicely with a simple
> example in the man page.

You don't need to list all the ports.  Like you said, "pkg prime-list >
my.list" and there's your top level.  Or "synth upgrade" system and
upgrade everything.  Either approach works.  The tight integration with
pkg is helpful.



> And, please, everyone, let's stop with the silly statements like "the
> Handbook should be limited to the base system" or "a maintainer needs to
> be able to fix all PRs". 

"All" is literal.  Nobody expects all PRs to be valid.
It's a moot point anyway, Torsten is now officially the maintainer
(based on faith I guess) so for now there's no issue.  Let's hope he is
successful.

John
___
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: Removing documentation

[Alphons van Werven]

Freddie Cash wrote:

>> A) An option is added
>> B) An option is removed
>> C) An option default changed.
>> D) Any other option configuration changed.
>>
>> Synth is the *only* tool that detects this.
 
> ???portmaster used to do this; was this option removed?  It was one of the
> nicer features of portmaster and really came in handy in the past.
> 
> Haven't used portmaster since 9.something when pkg really became useful
> and I stopped building anything from source, so maybe this feature was
> removed

???Between all the question marks (sorry, I just can't help myself) I
can reveal that Portmaster detects at least some of the above kinds of
changes. Perhaps not all four, but at least some (if not most).

I suspect it's probably not so much a matter of a feature having been
removed, but rather of Portmaster insufficiently keeping up with the ports
infrastructure in general and the options framework in particular. It's an
orphaned port after all.

Just an observation.

Fonz

-- 
obsig: developing a new sig


signature.asc
Description: PGP signature

Re: Removing documentation

[Lars Engels]

On Wed, Feb 10, 2016 at 01:15:58PM -0800, Kevin Oberman wrote:
> On Mon, Feb 8, 2016 at 1:55 AM, John Marino  wrote:
> 
> > On 2/8/2016 10:30 AM, Mathias Picker wrote:
> > > Am Montag, den 08.02.2016, 08:35 +0100 schrieb John Marino:
> > > While I like the ideas of synth, and hoped I could use it to just build
> > > my 3-8 ports with modified options, on first look I found many things
> > > suggesting that it's not yet ready:
> > >
> > > - shows uninteresting eye candy instead of build
> >
> > Every single port has it's own build log with far more detail that a
> > source build provides (similar to poudriere)
> >
> > > - stops at every conf file version mismatch requiring me to start make
> > > config by hand, and then to re-run when it discovers the next mismatch.
> > > I mean, WTF?
> >
> > This is incorrect.  It lists *ALL* the configuration mismatches at once.
> >  This is actually a huge "pro" for synth; no other tool detects this
> > mismatches.  It is far worse to have cached options that do not match
> > the current port.  The port can be misbuilt and it's a major pain to
> > troubleshoot.  All build tools should be doing this.  Are you really
> > proposing that a tool build a port with a bad configuration file?  You
> > should be thanking Synth for alerting to a problem you obviously didn't
> > know you had.
> >
> > Also, once you fix it, then configuration problems are rare, they occur
> > when the port changes.
> >
> 
> OK. I have been playing with synth and I must say that I find it
> impressive. Not that I am ready to put it into  "production", but
> impressive, none the less. Maybe after a bit more testing and updating all
> ports after moving from 10 to 11 (which will not be too soon). Still, it is
> way better than poudriere for my limited purposes. I will certainly use it
> for that, even if I still use portmaster for my "development" system.
> 
> The stale configuration file issue has me a bit confused. The man page does
> not make it clear just what makes a config "stale". All of my ports are up
> to date as of 11:00 UTC this morning. As far as I know, all of the configs
> are "current", although the actual config run may have been for a much
> older version. "synth status shows 46 cases. I looked at one
> (sysutils/tmux) and the options listed by "make showconfig" are no
> different from those in the current Makefile, so I don't understand why
> they are stale.
> 
> I also have found at least one thing portmster can do that synth can't, but
> I expect pkg can, so I won't complain about it until I have tried using pkg
> to list all top-level ports (nothing depends on them) to use to re-install
> all ports. I could list all ports, it's just that this is a much longer
> list and portmaster did the job nicely with a simple example in the man
> page.

You need to uncomment the "leaf" alias in /usr/local/etc/pkg.conf

leaf  'query -e "%a == 0" "%n-%v"'

Then "pkg leaf" works like pkg_cutleaves(8) or the portmaster option.



pgp7fz14CNcgV.pgp
Description: PGP signature

Re: Removing documentation

[Freddie Cash]

On Wed, Feb 10, 2016 at 1:46 PM, John Marino  wrote:

> On 2/10/2016 10:15 PM, Kevin Oberman wrote:
> >
> > The stale configuration file issue has me a bit confused. The man page
> > does not make it clear just what makes a config "stale". All of my ports
> > are up to date as of 11:00 UTC this morning. As far as I know, all of
> > the configs are "current", although the actual config run may have been
> > for a much older version. "synth status shows 46 cases. I looked at one
> > (sysutils/tmux) and the options listed by "make showconfig" are no
> > different from those in the current Makefile, so I don't understand why
> > they are stale.
>
> Stale isn't the right word.  You could use "invalid" or "obsolete"
> instead.  The saved configuration does not match the current port.
>
> Imagine a month ago you run "make config".  It saves the status of the 4
> options on this imaginary port.  Now imagine any of the following
> happening to the port.
>
> A) An option is added
> B) An option is removed
> C) An option default changed.
> D) Any other option configuration changed.
>
> Now the month-old saved configuration doesn't match the port.  See the
> problem?
>
> Synth is the *only* tool that detects this.


​portmaster used to do this; was this option removed?  It was one of the
nicer features of portmaster and really came in handy in the past.

Haven't used portmaster since 9.something when pkg really became useful and
I stopped building anything from source, so maybe this feature was removed?​


-- 
Freddie Cash
fjwc...@gmail.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: Removing documentation

[John Marino]

On 2/10/2016 10:37 AM, Lars Engels wrote:
> On Tue, Feb 09, 2016 at 06:28:11PM +0100, John Marino wrote:
>> On 2/9/2016 4:15 PM, Lars Engels wrote:
>>>
>>> root@fbsd01:~ # synth status
>>> Querying system about current package installations.
>>> Stand by, comparing installed packages against the ports tree.
>>> Stand by, building pkg(8) first ... Failed!!  (Synth must exit)
>>> Unfortunately, the system upgrade failed.
>>
>> Do you have a file called /var/log/synth/ports-mgmt___pkg.log ?  If so,
>> does it provide clues?
> 
> So it's missing the proxy variables.
> 

okay, so internally it's only installing resolv.conf in the builder
environment.  Where are these proxy variables defined?  When I
understand what's needed, I can give you a patch to try (if required)

Thanks,
John
___
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: maintaining portmaster ? was: Re: Removing documentation

[Kurt Jaeger]

Hi!

> >> I did take a look. I could do both: maintaining the port and maintaining 
> >> the software. What do you need? ;)
> >
> >Submit patches to the 12 PRs open for portmaster:
> >
> >https://bugs.freebsd.org/bugzilla/buglist.cgi?quicksearch=portmaster
> 
> That is just being silly.

Sorry if my mail was misinterpretable: I do not insist that Torsten
has to fix every single PR to become maintainer, far from it.

And I neither use portmaster nor synth in my setups, I use poudriere and
portupgrade, so I'm not really part of the debate.

Clearly, the documentation of the process in the handbook can be
improved, and if this involves some words on alternatives, its even
better.

> Providing a patch for one of
> the bugs would probably be sufficient for demonstrating interest
> and ability.

Yes, I understand that. It was not my intention to put up undue hurdles.

-- 
p...@opsec.eu+49 171 3101372 4 years to go !
___
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: Removing documentation

[John Marino]

On 2/10/2016 11:09 AM, Lars Engels wrote:
> On Wed, Feb 10, 2016 at 10:40:44AM +0100, John Marino wrote:
>> On 2/10/2016 10:37 AM, Lars Engels wrote:
>>> On Tue, Feb 09, 2016 at 06:28:11PM +0100, John Marino wrote:
 On 2/9/2016 4:15 PM, Lars Engels wrote:
>
> root@fbsd01:~ # synth status
> Querying system about current package installations.
> Stand by, comparing installed packages against the ports tree.
> Stand by, building pkg(8) first ... Failed!!  (Synth must exit)
> Unfortunately, the system upgrade failed.

 Do you have a file called /var/log/synth/ports-mgmt___pkg.log ?  If so,
 does it provide clues?
>>>
>>> So it's missing the proxy variables.
>>>
>>
>> okay, so internally it's only installing resolv.conf in the builder
>> environment.  Where are these proxy variables defined?  When I
>> understand what's needed, I can give you a patch to try (if required)
> 
> resolv.conf doesn't work in that proxy scenario. DNS requests are
> handled by the proxy server.
> 
> I set
> HTTP_PROXY=http://proxyserver:; export HTTP_PROXY
> http_proxy=http://proxyserver:; export http_proxy
> ftp_proxy=http://proxyserver:; export FTP_PROXY
> ftp_proxy=http://proxyserver:; export ftp_proxy
> 
> NO_PROXY="localhost,127.0.0.1,..."; export NO_PROXY
> 
> in /etc/profile and
> :setenv=MAIL=/var/mail/$,BLOCKSIZE=K,HTTP_PROXY=http\c//proxyserver\c,FTP_PROXY=http\c//proxyserver\c,NO_PROXY=localhost\054127.0.0.1\054...:\
> 
> in /etc/login.conf
> 

wow, okay, so basically these 4 variables would have to be present in
the builder environment then?

I'll have to think about this.  I'll probably have to add a feature like
a file like "/usr/local/etc/synth/-environment which will
append user environment variables to the stock ones.

That's not exactly a 1-line change, but would that solve this issue?

John


___
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: Removing documentation

[Lars Engels]

On Wed, Feb 10, 2016 at 10:40:44AM +0100, John Marino wrote:
> On 2/10/2016 10:37 AM, Lars Engels wrote:
> > On Tue, Feb 09, 2016 at 06:28:11PM +0100, John Marino wrote:
> >> On 2/9/2016 4:15 PM, Lars Engels wrote:
> >>>
> >>> root@fbsd01:~ # synth status
> >>> Querying system about current package installations.
> >>> Stand by, comparing installed packages against the ports tree.
> >>> Stand by, building pkg(8) first ... Failed!!  (Synth must exit)
> >>> Unfortunately, the system upgrade failed.
> >>
> >> Do you have a file called /var/log/synth/ports-mgmt___pkg.log ?  If so,
> >> does it provide clues?
> > 
> > So it's missing the proxy variables.
> > 
> 
> okay, so internally it's only installing resolv.conf in the builder
> environment.  Where are these proxy variables defined?  When I
> understand what's needed, I can give you a patch to try (if required)

resolv.conf doesn't work in that proxy scenario. DNS requests are
handled by the proxy server.

I set
HTTP_PROXY=http://proxyserver:; export HTTP_PROXY
http_proxy=http://proxyserver:; export http_proxy
ftp_proxy=http://proxyserver:; export FTP_PROXY
ftp_proxy=http://proxyserver:; export ftp_proxy

NO_PROXY="localhost,127.0.0.1,..."; export NO_PROXY

in /etc/profile and
:setenv=MAIL=/var/mail/$,BLOCKSIZE=K,HTTP_PROXY=http\c//proxyserver\c,FTP_PROXY=http\c//proxyserver\c,NO_PROXY=localhost\054127.0.0.1\054...:\

in /etc/login.conf



pgpKuGecm22cx.pgp
Description: PGP signature

Re: Removing documentation

[Lars Engels]

My rather short experience:

Synth configuration profile: LiveSystem
===
   [A] Ports directory/usr/ports
   [B] Packages directory /var/synth/live_packages
   [C] Distfiles directory/usr/ports/distfiles
   [D] Port options directory /var/db/ports
   [E] Build logs directory   /var/log/synth
   [F] Build base directory   /usr/obj/synth-live
   [G] System root directory  /
   [H] Compiler cache directory   disabled
   [I] Num. concurrent builders   6
   [J] Max. jobs per builder  4
   [K] Use tmpfs for work areatrue
   [L] Use tmpfs for /usr/local   true
   [M] Display using ncurses  true
   [N] Fetch prebuilt packagestrue

   [>]   Switch/create profiles
   [RET] Exit

Press key of selection:
root@fbsd01:~ # synth status
Querying system about current package installations.
Stand by, comparing installed packages against the ports tree.
Stand by, building pkg(8) first ... Failed!!  (Synth must exit)
Unfortunately, the system upgrade failed.
root@fbsd01:~ # uname -a
FreeBSD fbsd01 10.2-RELEASE-p9 FreeBSD 10.2-RELEASE-p9 #0: Thu Jan 14 01:32:46 
UTC 2016 r...@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC  
amd64
root@fbsd01:~ #


Not a very verbose message why it actually failed.
I need a proxy server to access the internet. Could this be the problem?
*_[pP][rR][oO][xX][yY] env vars are all set, though.


pgpCiYdOtis8M.pgp
Description: PGP signature

Re: Removing documentation

[John Marino]

On 2/9/2016 9:27 PM, John Marino wrote:
> On 2/9/2016 9:20 PM, Warren Block wrote:
>> On Tue, 9 Feb 2016, John Marino wrote:
>>
>>> On 2/9/2016 7:20 PM, Warren Block wrote:
> If you have the build log, I'd like to see it.  Dewayne G. got an error
> after overriding CPUTYPE (do you do that too?) and I'm thinking it's
> sensitive to CPU and I'd like to know more.

 Yes, I use

 CPUTYPE?=core-avx2
>>>
>>> What happens when you try to build lang/gcc6-devel ?
>>> Same issue or does it complete?
>>
>> It builds successfully, in about 40 minutes.
> 
> My suspicion is that due to the bootstrap, we'd have two possible options:
> A) turn on the full bootstrap which takes the same amount of time as
> gcc6-devel does (I'm not sure it will work but there's a chance)
> B) I put CPUTYPE=native in the gcc6-aux Makefile
> 
> I am inclined towards B.  It works on DragonFly but I need somebody else
> to test it on i7 on FreeBSD.  I asked Dewayne, but I'd be grateful if
> you could test it as well.

Hi Warren,
Dewayne got back to me, and it appears the only solution is to put
"CPUTYPE=" in the gcc6-aux makefile.  I think the bootstrap compiler
(the ada-capable compiler downloaded to build gcc6-aux) doesn't know
these instructions and that's the issue.  The options are don't override
CPUTYPE or regenerate the bootstrap, but that might have other
consequences or won't fix every combination.

John


___
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: Removing documentation

[Lars Engels]

On Wed, Feb 10, 2016 at 11:16:10AM +0100, John Marino wrote:
> On 2/10/2016 11:09 AM, Lars Engels wrote:
> > On Wed, Feb 10, 2016 at 10:40:44AM +0100, John Marino wrote:
> >> On 2/10/2016 10:37 AM, Lars Engels wrote:
> >>> On Tue, Feb 09, 2016 at 06:28:11PM +0100, John Marino wrote:
>  On 2/9/2016 4:15 PM, Lars Engels wrote:
> >
> > root@fbsd01:~ # synth status
> > Querying system about current package installations.
> > Stand by, comparing installed packages against the ports tree.
> > Stand by, building pkg(8) first ... Failed!!  (Synth must exit)
> > Unfortunately, the system upgrade failed.
> 
>  Do you have a file called /var/log/synth/ports-mgmt___pkg.log ?  If so,
>  does it provide clues?
> >>>
> >>> So it's missing the proxy variables.
> >>>
> >>
> >> okay, so internally it's only installing resolv.conf in the builder
> >> environment.  Where are these proxy variables defined?  When I
> >> understand what's needed, I can give you a patch to try (if required)
> > 
> > resolv.conf doesn't work in that proxy scenario. DNS requests are
> > handled by the proxy server.
> > 
> > I set
> > HTTP_PROXY=http://proxyserver:; export HTTP_PROXY
> > http_proxy=http://proxyserver:; export http_proxy
> > ftp_proxy=http://proxyserver:; export FTP_PROXY
> > ftp_proxy=http://proxyserver:; export ftp_proxy
> > 
> > NO_PROXY="localhost,127.0.0.1,..."; export NO_PROXY
> > 
> > in /etc/profile and
> > :setenv=MAIL=/var/mail/$,BLOCKSIZE=K,HTTP_PROXY=http\c//proxyserver\c,FTP_PROXY=http\c//proxyserver\c,NO_PROXY=localhost\054127.0.0.1\054...:\
> > 
> > in /etc/login.conf
> > 
> 
> wow, okay, so basically these 4 variables would have to be present in
> the builder environment then?
> 
> I'll have to think about this.  I'll probably have to add a feature like
> a file like "/usr/local/etc/synth/-environment which will
> append user environment variables to the stock ones.
> 
> That's not exactly a 1-line change, but would that solve this issue?

That should work, yes.


pgpieLkC5c1Qe.pgp
Description: PGP signature

Re: maintaining portmaster ? was: Re: Removing documentation

[Torsten Zuehlsdorff]

On 10.02.2016 06:47, Peter Jeremy wrote:

On 2016-Feb-09 21:24:56 +0100, Kurt Jaeger  wrote:

Torsten wrote:


I did take a look. I could do both: maintaining the port and maintaining
the software. What do you need? ;)


Submit patches to the 12 PRs open for portmaster:

https://bugs.freebsd.org/bugzilla/buglist.cgi?quicksearch=portmaster


That is just being silly.

I'd start by triaging those bugs.  One is clearly a kernel bug,
another maybe a bug in a different port and one is described as a
feature request.  The remaining 9 may or may not still be bugs in
portmaster that are still relevant.  Providing a patch for one of
the bugs would probably be sufficient for demonstrating interest
and ability.


The discussion also put some attention at the existing PRs. Walter 
already tried to reproduce some of the PRs and give some feedback, for 
example that an issue is not reproducibly at the current time. I think 
this will be true for most of the PRs.


One already brings a patch with it. The first work will be most 
management of the PRs.


I'm asking myself how to manage the code. Should i create a new GitHub 
repository? Fork the existing from freebsd/portmaster? How to handle the 
LOCAL Master-Site?


I submitted a PR to take maintainer-ship for portmaster:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207075

Also i fix some minor glitches and add missing RUN_DEPENDS.

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: Removing documentation

[Lars Engels]

On Tue, Feb 09, 2016 at 06:28:11PM +0100, John Marino wrote:
> On 2/9/2016 4:15 PM, Lars Engels wrote:
> > 
> > root@fbsd01:~ # synth status
> > Querying system about current package installations.
> > Stand by, comparing installed packages against the ports tree.
> > Stand by, building pkg(8) first ... Failed!!  (Synth must exit)
> > Unfortunately, the system upgrade failed.
> 
> Do you have a file called /var/log/synth/ports-mgmt___pkg.log ?  If so,
> does it provide clues?
> 
> John

=> pkg-1.6.3.tar.xz doesn't seem to exist in /distfiles/.
=> Attempting to fetch http://files.etoilebsd.net/pkg/pkg-1.6.3.tar.xz
fetch: http://files.etoilebsd.net/pkg/pkg-1.6.3.tar.xz: No address record
=> Attempting to fetch 
http://distcache.FreeBSD.org/local-distfiles/portmgr/pkg-1.6.3.tar.xz
fetch: http://distcache.FreeBSD.org/local-distfiles/portmgr/pkg-1.6.3.tar.xz: 
No address record
=> Attempting to fetch 
http://distcache.us-east.FreeBSD.org/local-distfiles/portmgr/pkg-1.6.3.tar.xz
fetch: 
http://distcache.us-east.FreeBSD.org/local-distfiles/portmgr/pkg-1.6.3.tar.xz: 
No address record
=> Attempting to fetch 
http://distcache.eu.FreeBSD.org/local-distfiles/portmgr/pkg-1.6.3.tar.xz
fetch: 
http://distcache.eu.FreeBSD.org/local-distfiles/portmgr/pkg-1.6.3.tar.xz: No 
address record
=> Attempting to fetch 
http://distcache.us-west.FreeBSD.org/local-distfiles/portmgr/pkg-1.6.3.tar.xz
fetch: 
http://distcache.us-west.FreeBSD.org/local-distfiles/portmgr/pkg-1.6.3.tar.xz: 
No address record
=> Attempting to fetch http://mirror.shatow.net/freebsd/pkg/pkg-1.6.3.tar.xz
fetch: http://mirror.shatow.net/freebsd/pkg/pkg-1.6.3.tar.xz: No address record
=> Attempting to fetch 
http://distcache.FreeBSD.org/ports-distfiles/pkg-1.6.3.tar.xz
fetch: http://distcache.FreeBSD.org/ports-distfiles/pkg-1.6.3.tar.xz: No 
address record
=> Couldn't fetch it - please try to retrieve this
=> port manually into /distfiles/ and try again.


So it's missing the proxy variables.


pgpb4YOGt1H9b.pgp
Description: PGP signature

Re: Removing documentation

[Torsten Zühlsdorff]

On 08.02.2016 01:02, Warren Block wrote:

On Sun, 7 Feb 2016, Torsten Zühlsdorff wrote:


Hello,


You have a tool presented as "official" that hasn't had it's
original maintainer in 4 years and was only kept on life support up
until 9 months ago.


Agreed, the "official" (the term used is "recommended") status is
gone.  But that's a reason to fix the documentation, not remove it.
As I see it, we have three choices, in increasing order of
desirability:

1.  Remove all mention of portmaster.  That's what this PR recommends.
2.  Do nothing.
3.  Update the documentation to indicate the current status,
 recommending alternatives if possible.


Number 4 is missing: find a maintainer for it.

I would volunteer for this. But before a real commitment i need a
closer look at it, which i will do next week. So please standby.


Thank you.


I did take a look. I could do both: maintaining the port and maintaining 
the software. What do you need? ;)


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: Removing documentation

[Torsten Zühlsdorff]

On 08.02.2016 02:18, Greg 'groggy' Lehey wrote:

On Sunday,  7 February 2016 at 12:44:32 +0100, Torsten Zühlsdorff wrote:

Hello,


You have a tool presented as "official" that hasn't had it's
original maintainer in 4 years and was only kept on life support up
until 9 months ago.


Agreed, the "official" (the term used is "recommended") status is
gone.  But that's a reason to fix the documentation, not remove it.
As I see it, we have three choices, in increasing order of
desirability:

1.  Remove all mention of portmaster.  That's what this PR recommends.
2.  Do nothing.
3.  Update the documentation to indicate the current status,
  recommending alternatives if possible.


Number 4 is missing: find a maintainer for it.


Yes.  It was there in my draft, and I removed it.  It's a separate
issue: I was asking here about what to do with documentation for used,
but unmaintained packages.  But you make a good point: if there's a
lapse in maintainership, and the product then becomes maintained
again, you don't want to lose the documentation.


There is another point hidden: you don't want to lose the software itself.
At the moment i'm maintaining a greater number of software (also outside 
FreeBSD). Every one of it is abandoned but very good. Every one is 
feature complete and needs just small fixes for example when the 
compiler requires this or a bug is found. Many software get lost (and 
later reinvented with all needed maturing) because the author did not 
maintain it anymore. While i dislike this kind of work we should be 
fair: there is software which fulfill its purpose of its niche and just 
need to keep running.


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: Removing documentation

[John Marino]

On 2/9/2016 7:20 PM, Warren Block wrote:
>> If you have the build log, I'd like to see it.  Dewayne G. got an error
>> after overriding CPUTYPE (do you do that too?) and I'm thinking it's
>> sensitive to CPU and I'd like to know more.
> 
> Yes, I use
> 
> CPUTYPE?=core-avx2

What happens when you try to build lang/gcc6-devel ?
Same issue or does it complete?

Thanks,
John
___
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"

maintaining portmaster ? was: Re: Removing documentation

[Kurt Jaeger]

Hi!

Torsten wrote:

> I did take a look. I could do both: maintaining the port and maintaining 
> the software. What do you need? ;)

Submit patches to the 12 PRs open for portmaster:

https://bugs.freebsd.org/bugzilla/buglist.cgi?quicksearch=portmaster

-- 
p...@opsec.eu+49 171 3101372 4 years to go !
___
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: Removing documentation

[Ernie Luzar]

Kevin Oberman wrote:

On Sat, Feb 6, 2016 at 4:03 PM, Greg 'groggy' Lehey 
wrote:


I'm bringing this to the attention of the ports community to try to
come up with a consensus about how to handle existing documentation
for ageing packages, in this case portmaster.

This bug report suggests removing the documentation for portmaster
because it is out of date and no longer maintained.




3 or 4 years ago the handbook never recommended any port. Only utility 
tools contained in the base release were allowed to be documented in the 
handbook. This standard should be enforced again. The tool portmaster 
and ezjail should be removed from the handbook or be included as part of 
the base system release.

___
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: Removing documentation (was: [Bug 206922] Handbook: Chapter 4.5+ changes)

[Baptiste Daroussin]

On Sun, Feb 07, 2016 at 11:03:04AM +1100, Greg 'groggy' Lehey wrote:
> I'm bringing this to the attention of the ports community to try to
> come up with a consensus about how to handle existing documentation
> for ageing packages, in this case portmaster.
> 
> This bug report suggests removing the documentation for portmaster
> because it is out of date and no longer maintained.
> 
> But it's still in the ports tree, and people still use it.  The
> current wording (4.5.3.1) claims it is the recommended tool, which is
> clearly out of date.  marino@ (the submitter) writes:
> 
> On Friday,  5 February 2016 at  7:33:33 +, bugzilla-nore...@freebsd.org 
> wrote:
> >
> > You have a tool presented as "official" that hasn't had it's
> > original maintainer in 4 years and was only kept on life support up
> > until 9 months ago.
> 
> Agreed, the "official" (the term used is "recommended") status is
> gone.  But that's a reason to fix the documentation, not remove it.
> As I see it, we have three choices, in increasing order of
> desirability:
> 
> 1.  Remove all mention of portmaster.  That's what this PR recommends.
> 2.  Do nothing.
> 3.  Update the documentation to indicate the current status,
> recommending alternatives if possible.
> 
> The real issue here is that we shouldn't remove documentation for
> software that is still available.  In addition, wblock@ writes:
> 
> On Friday,  5 February 2016 at 14:48:07 +, bugzilla-nore...@freebsd.org 
> wrote:
> >
> > At present, portmaster still has no direct competition...
> 
> More generally, the way I see it is simple: we should try to keep the
> documentation as up-to-date as possible.  This means that we don't
> remove documentation for existing packages.  It also means that we may
> need to change the content of the documentation if the status (not
> necessarily the content) of the package changes.
> 
> One of the arguments for removing it from the handbook is that it has
> a man page.  That has some merit, but it doesn't help the people who
> have used portmaster and now don't know what to do.  Even if portmgr
> is deprecated, the documentation should suggest a replacement.
> 
> Can portmgr@ come up with a clear, easy-to-understand policy?
> 

In my opinion there is no reason to remove the mention of portmaster in the
handbook as long as it is not "official" and "recommended" but just listed as a
possible tools.

There are plenty of documentation on the handbook to explain how to use $third
party tools.

portmaster has some design flaws and clearly synth has a way better and safer
one. But that does not mean portmaster is ready to go away as there are plenty
of users using it still and for some cases, no alternative is available.

For instance, as far as I know synth is not available on non i386/amd64
architectures which is imho the major issue for being a candidate for a
replacement of portmaster.

As much as I don't like the way portmaster (and portupgrade) are designed: aka
unsafe building, there are still IMHO no alternative by the fact that an
alternative should cover all our supported architectures. For i386/amd64 users
yes synth is a viable alternative and a way safer one. Also note that synth is
still very young and before pushing anything that would kill others, it would be
good to be more patient and and see how the tool behave/is adopted/is maintained
over the time.

Regarding portmaster, I think it would be time to deprecate it and remove it
from the ports tree/documentation the day when it prevents us from adding an
important feature into the ports tree, which may or may not happen soon.

Out of my mind such features could be:
- subpackages
- flavours/variant

Note that the above would require changes in all the port management tools. Also
note that as far as I know noone is working on the first (subpackages) and
someone picked up the work on flavours/variants based on where I stopped but I
don't think it will land in the ports tree any time soon. (also note I'm not
working on those feature anymore for now, because of ENOTIME :()

BTW: just a clarification on the dependency front:
- at runtime synth depends on only 1 port: ncurses
- at bulidtime it depends on 2 ports: ada (gcc-aux)/ncurses (gcc-aux itself my
  drag other build dependency.

Best regards,
Bapt


signature.asc
Description: PGP signature

Re: Removing documentation

[John Marino]

On 2/9/2016 11:52 AM, Hrant Dadivanyan wrote:
> It's fine that there is such an excellent tool as synth, but in server
> environment, when only a few ports are installed, having a management port
> with 17 dependencies is not reasonable. 

Rather that parroting this phrase, I would like to see some technical
reasoning about this dependency criticism.  Would you be willing to
provide that?

What I would like to see you address is:

1) As was just stated earler this morning, having synth installed is 2
packages: Synth itself and ncurses.  These "17 dependences" are build
requirements and not installed.  So what is "unreasonable" about that?

2) If 17 dependencies are such a concern, why would you not install it
via official freebsd packages?

3) If there is a corporate policy to build everything from source, what
would be the issue to use an officially packaged Synth to build Synth
(along with the other packages) so that the locally built Synth could
replace the downloaded version?

As established earlier both by text and the recently posted architecture
drawing, Synth is not in the critical path and removing it has no
adverse affects on a system so the whole, "I'll be left in a bad state
argument has been debunked"

This is not a rhetorical set of questions, I would very much like to see
how you answer these, given your opinion on this is unreasonable.  I
would like to understand how this is a problem and why there are no ways
to address it.

thank you,
John
___
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: Removing documentation

[Hrant Dadivanyan]

> > Then allow me to be the second.  But then, I find poudriere
> > unusable on my build system (I don't use ZFS and my memory is
> > apparently too limited).  Portmaster just does the right thing.
> > 
> > We get that you don't like portmaster.  So please don't use it.
> > But don't deprive the rest of us.  -- George
> 
> Did you actually install it, use it, and compare?
> Or are you just saying this based on what you think it does?
> 
> So far every former portmaster use that tried it (really tried it) has
> switch with one possible exception (he didn't see the rationale for the
> build logic so I don't know if he kept using it or not).
> 
> And not one person until Mattias said portmaster was "easier".
> 
> BTW, if your system is too limited for poudriere, then likely you
> couldn't use tmpfs with Synth, so you'd lose out on a lot of
> performance.  It would still be better than live building though.

It's fine that there is such an excellent tool as synth, but in server
environment, when only a few ports are installed, having a management port
with 17 dependencies is not reasonable. From the very beginning portmaster
works fine for me and, as far as I can see, for many other people.

>From my point it's mandatory to have a lightweight tool like postmaster is
and the question should be how to maintain it, instead of how limited it is.

Thank you,
Hrant

> ___
> 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: Removing documentation

[Baptiste Daroussin]

On Tue, Feb 09, 2016 at 04:02:53PM +0800, Ernie Luzar wrote:
> Kevin Oberman wrote:
> > On Sat, Feb 6, 2016 at 4:03 PM, Greg 'groggy' Lehey 
> > wrote:
> > 
> >> I'm bringing this to the attention of the ports community to try to
> >> come up with a consensus about how to handle existing documentation
> >> for ageing packages, in this case portmaster.
> >>
> >> This bug report suggests removing the documentation for portmaster
> >> because it is out of date and no longer maintained.
> >>
> 
> 
> 3 or 4 years ago the handbook never recommended any port. Only utility 
> tools contained in the base release were allowed to be documented in the 
> handbook. This standard should be enforced again. The tool portmaster 
> and ezjail should be removed from the handbook or be included as part of 
> the base system release.

I would be sad to see any documentation about the package manager going away
from the handbook.

I would be sad to see any documentation about X configuration (which where there
for sure 3 or 4 years ago going away)

I would be sad to see any documentation about ldap going away (iirc also older
than 3 or 4 years ago)

What about the http documentation, thhe samba one?

Clearly the handbook has always documented tools that are not available in base.

Best regards,
Bapt


signature.asc
Description: PGP signature

Re: Removing documentation

[Jim Ohlstein]

On 2/9/16 9:08 AM, John Marino wrote:

On 2/9/2016 2:46 PM, Jim Ohlstein wrote:

After all of this "discussion" I decided to give synth a try. I have no
pony in this race as I use neither portmaster nor portupgrade. Both may
still be in my repo, but they are not installed.


Thanks for trying it!



The build time of "like 20-30 minutes, at most" is ummm... let' just
call it optimistic. I only needed five new dependencies. Poudriere was
unable to take advantage of more than two parallel builders except for a
rather short overlap where it used three, if I recall correctly. The
vast majority of the time it used only one builder. Build and package
time for gcc6-aux was 34:52 on an Intel E5-2650 v3. Build and package
time for binutils, required for gcc6-aux, took 4:44. That's pretty close


hmmm, my core i5 builds it in 10-12 minutes and I've had it ~4 years?
I'm not sure why such a big descreptancy, but newer machines with 4-8Gb
or more ram should have no issues with time.


Interesting. I just tested again and got 31:47. To be fair, I only allow 
that VM four cores. Perhaps it might do better with more?





to 40 minutes for just two dependencies, one of which is a dependency of
the other. Build and package time for synth was 1:09.

I installed synth and had a look at the man page. Nice job on the
documentation though I might suggest more real world examples, in an
"Examples" section at the end, would be helpful to people like me who
want to understand how to get started. Sort of like a "quick start
guide" that comes with a new electronic component. Get it going and then
read the details on what's really important for the specific use case.
That shouldn't be construed as a knock on the documentation, which
really is very good.


Do you think the illustrated README on the github page is helpful?

https://github.com/jrmarino/synth



Yes, I do indeed. Thanks.




This was last night and I haven't tried building with it yet. I need to
re-read the documentation. I do however have concerns, the biggest of
which is, yes, the dependencies. I use poudriere because I like to build
packages myself for my installations and with my options, so using the
FreeBSD repo version of synth will be a non-starter. That means that
I'll need to rebuild gcc6-aux every time I need to rebuild synth,
assuming gcc6-aux has been updated. It's a fair guess that gcc6-aux is
regularly updated (the current version is dated 20160124). It's also a


After gcc6 hits release (6.1), it will probably only be released with
every point release (6.2, 6.3), which are separated by months.


fair guess that synth will go through a few iterations in the short term
given its youth. Looking at my recent build logs, the longest builds I


It's feature complete and v1.00 is coming out in a few days (same as
0.99_6 with a version bump).  v1.1 will come soon after when I improve
on the build-repository command to not scan the entire tree.  It's
already been through the iterations, so I don't there will be that many
more.  In any case, it's a small problem (and when gcc6-aux is released,
it won't build the bundled libraries anymore but use other ports so it
will be much, much faster to compile.



run are far shorter than 35 minutes. This will slow things down and I'm
not certain I'm going to be willing to keep a package in my repo that
requires that amount of build time just as a dependency I otherwise
would never build. To be honest, synth, which I will try, will have to
be _far_ superior to poudriere in order to replace it as my tool of
choice. Of course that's my use case and mine only.


To be fair, poudriere users aren't the target audience.  Yes, it's
significantly faster than poudriere and maybe people like the interface
better, but if they are already set up on poudriere and happy with it,
that's a fine choice too.

It's more for people that aren't using poudriere, really should be, but
are intimidated by it.



--
Jim Ohlstein


"Never argue with a fool, onlookers may not be able to tell the 
difference." - Mark Twain

___
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: Removing documentation

[John Marino]

On 2/9/2016 2:46 PM, Jim Ohlstein wrote:
> After all of this "discussion" I decided to give synth a try. I have no
> pony in this race as I use neither portmaster nor portupgrade. Both may
> still be in my repo, but they are not installed.

Thanks for trying it!

> 
> The build time of "like 20-30 minutes, at most" is ummm... let' just
> call it optimistic. I only needed five new dependencies. Poudriere was
> unable to take advantage of more than two parallel builders except for a
> rather short overlap where it used three, if I recall correctly. The
> vast majority of the time it used only one builder. Build and package
> time for gcc6-aux was 34:52 on an Intel E5-2650 v3. Build and package
> time for binutils, required for gcc6-aux, took 4:44. That's pretty close

hmmm, my core i5 builds it in 10-12 minutes and I've had it ~4 years?
I'm not sure why such a big descreptancy, but newer machines with 4-8Gb
or more ram should have no issues with time.

> to 40 minutes for just two dependencies, one of which is a dependency of
> the other. Build and package time for synth was 1:09.
> 
> I installed synth and had a look at the man page. Nice job on the
> documentation though I might suggest more real world examples, in an
> "Examples" section at the end, would be helpful to people like me who
> want to understand how to get started. Sort of like a "quick start
> guide" that comes with a new electronic component. Get it going and then
> read the details on what's really important for the specific use case.
> That shouldn't be construed as a knock on the documentation, which
> really is very good.

Do you think the illustrated README on the github page is helpful?

https://github.com/jrmarino/synth


> This was last night and I haven't tried building with it yet. I need to
> re-read the documentation. I do however have concerns, the biggest of
> which is, yes, the dependencies. I use poudriere because I like to build
> packages myself for my installations and with my options, so using the
> FreeBSD repo version of synth will be a non-starter. That means that
> I'll need to rebuild gcc6-aux every time I need to rebuild synth,
> assuming gcc6-aux has been updated. It's a fair guess that gcc6-aux is
> regularly updated (the current version is dated 20160124). It's also a

After gcc6 hits release (6.1), it will probably only be released with
every point release (6.2, 6.3), which are separated by months.

> fair guess that synth will go through a few iterations in the short term
> given its youth. Looking at my recent build logs, the longest builds I

It's feature complete and v1.00 is coming out in a few days (same as
0.99_6 with a version bump).  v1.1 will come soon after when I improve
on the build-repository command to not scan the entire tree.  It's
already been through the iterations, so I don't there will be that many
more.  In any case, it's a small problem (and when gcc6-aux is released,
it won't build the bundled libraries anymore but use other ports so it
will be much, much faster to compile.


> run are far shorter than 35 minutes. This will slow things down and I'm
> not certain I'm going to be willing to keep a package in my repo that
> requires that amount of build time just as a dependency I otherwise
> would never build. To be honest, synth, which I will try, will have to
> be _far_ superior to poudriere in order to replace it as my tool of
> choice. Of course that's my use case and mine only.

To be fair, poudriere users aren't the target audience.  Yes, it's
significantly faster than poudriere and maybe people like the interface
better, but if they are already set up on poudriere and happy with it,
that's a fine choice too.

It's more for people that aren't using poudriere, really should be, but
are intimidated by it.

John
___
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: Removing documentation

[Hrant Dadivanyan]

> On 2/9/2016 11:52 AM, Hrant Dadivanyan wrote:
> > It's fine that there is such an excellent tool as synth, but in server
> > environment, when only a few ports are installed, having a management port
> > with 17 dependencies is not reasonable. 
> 
> Rather that parroting this phrase, I would like to see some technical
> reasoning about this dependency criticism.  Would you be willing to
> provide that?
> 
> What I would like to see you address is:
> 
> 1) As was just stated earler this morning, having synth installed is 2
> packages: Synth itself and ncurses.  These "17 dependences" are build
> requirements and not installed.  So what is "unreasonable" about that?
>

So will require any upgrade of synth by itself, correct ? If build from
sources, of course.
 
> 2) If 17 dependencies are such a concern, why would you not install it
> via official freebsd packages?
> 

Ports buiding is also official. Phrasing of your question sets the
preference in favour of prebuilt packages, my preference is opposite.

> 3) If there is a corporate policy to build everything from source, what
> would be the issue to use an officially packaged Synth to build Synth
> (along with the other packages) so that the locally built Synth could
> replace the downloaded version?
> 

In my case it's just a preference to build everything locally.

> As established earlier both by text and the recently posted architecture
> drawing, Synth is not in the critical path and removing it has no
> adverse affects on a system so the whole, "I'll be left in a bad state
> argument has been debunked"
> 
> This is not a rhetorical set of questions, I would very much like to see
> how you answer these, given your opinion on this is unreasonable.  I
> would like to understand how this is a problem and why there are no ways
> to address it.
> 

There is no need to address it, because of two quite different use cases.
As far as I can see synth is excellent in some cases, my point is that
portmaster is fine in some other ones.

> thank you,
> John

-- 
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: Removing documentation

[John Marino]

On 2/9/2016 12:45 PM, Hrant Dadivanyan wrote:
>> 1) As was just stated earler this morning, having synth installed is 2
>> packages: Synth itself and ncurses.  These "17 dependences" are build
>> requirements and not installed.  So what is "unreasonable" about that?
> 
> So will require any upgrade of synth by itself, correct ? If build from
> sources, of course.

You don't build all 17 dependencies every time, it's incremental. And
even if you did, it would take like 20-30 minutes, at most (mainly gcc).
 I would not call that "unreasonable" because time isn't critical here.
 Most of the dependences are common to other packages too.


>> 2) If 17 dependencies are such a concern, why would you not install it
>> via official freebsd packages?
> 
> Ports buiding is also official. Phrasing of your question sets the
> preference in favour of prebuilt packages, my preference is opposite.

I don't think that's really answering the question.  That's a case where
you consciously reject a fast, easy solution for a different one, but
then don't accept the consequences.  Yes, it's fine fine to build form
ports (although I would be careful with "official" because everything is
pushing towards packages), but if you choose to build from source, you
are choosing to also build the build dependencies.  That's not something
you have to do.  I would actually say that complaining about known
consequences of an conscious decision is unreasonable.

by the way, packages *are* favoured.  That's been the case for a while.


> In my case it's just a preference to build everything locally.

so the cost for this preference is extra time and extra building.
That's fine.  The build dependencies are not installed.  Obtaining synth
from building on /usr/ports works too, but then the build dependencies
*are* installed.  So using a provided package would be the better way to
avoid the extra installations.


> There is no need to address it, because of two quite different use cases.
> As far as I can see synth is excellent in some cases, my point is that
> portmaster is fine in some other ones.

I did want to point out that there are many known bugs and open reports,
so it's not "fine" for everyone.  You've apparently not hit them so
that's great for you.

Actually, I don't care what you use, but the using build dependencies as
a justification for not using it and labelling it "unreasonable" at the
same time, I just wanted that expanded on.  I don't know if you still
think it's unreasonable, but I do appreciate that you took the time to
respond.

P.S.  If FreeBSD 11 didn't regress with ncurses (PR 199109) then
probably we could provide synth with NO runtime dependencies.  But there
doesn't seem to be any interest in fixing the regression unfortunately.




___
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: Removing documentation

[Jim Ohlstein]

Hello,

On 2/9/16 7:05 AM, John Marino wrote:

On 2/9/2016 12:45 PM, Hrant Dadivanyan wrote:

1) As was just stated earler this morning, having synth installed is 2
packages: Synth itself and ncurses.  These "17 dependences" are build
requirements and not installed.  So what is "unreasonable" about that?


So will require any upgrade of synth by itself, correct ? If build from
sources, of course.


You don't build all 17 dependencies every time, it's incremental. And
even if you did, it would take like 20-30 minutes, at most (mainly gcc).
  I would not call that "unreasonable" because time isn't critical here.
  Most of the dependences are common to other packages too.



After all of this "discussion" I decided to give synth a try. I have no 
pony in this race as I use neither portmaster nor portupgrade. Both may 
still be in my repo, but they are not installed.


The build time of "like 20-30 minutes, at most" is ummm... let' just 
call it optimistic. I only needed five new dependencies. Poudriere was 
unable to take advantage of more than two parallel builders except for a 
rather short overlap where it used three, if I recall correctly. The 
vast majority of the time it used only one builder. Build and package 
time for gcc6-aux was 34:52 on an Intel E5-2650 v3. Build and package 
time for binutils, required for gcc6-aux, took 4:44. That's pretty close 
to 40 minutes for just two dependencies, one of which is a dependency of 
the other. Build and package time for synth was 1:09.


I installed synth and had a look at the man page. Nice job on the 
documentation though I might suggest more real world examples, in an 
"Examples" section at the end, would be helpful to people like me who 
want to understand how to get started. Sort of like a "quick start 
guide" that comes with a new electronic component. Get it going and then 
read the details on what's really important for the specific use case. 
That shouldn't be construed as a knock on the documentation, which 
really is very good.


This was last night and I haven't tried building with it yet. I need to 
re-read the documentation. I do however have concerns, the biggest of 
which is, yes, the dependencies. I use poudriere because I like to build 
packages myself for my installations and with my options, so using the 
FreeBSD repo version of synth will be a non-starter. That means that 
I'll need to rebuild gcc6-aux every time I need to rebuild synth, 
assuming gcc6-aux has been updated. It's a fair guess that gcc6-aux is 
regularly updated (the current version is dated 20160124). It's also a 
fair guess that synth will go through a few iterations in the short term 
given its youth. Looking at my recent build logs, the longest builds I 
run are far shorter than 35 minutes. This will slow things down and I'm 
not certain I'm going to be willing to keep a package in my repo that 
requires that amount of build time just as a dependency I otherwise 
would never build. To be honest, synth, which I will try, will have to 
be _far_ superior to poudriere in order to replace it as my tool of 
choice. Of course that's my use case and mine only.






2) If 17 dependencies are such a concern, why would you not install it
via official freebsd packages?


Ports buiding is also official. Phrasing of your question sets the
preference in favour of prebuilt packages, my preference is opposite.


I don't think that's really answering the question.  That's a case where
you consciously reject a fast, easy solution for a different one, but
then don't accept the consequences.  Yes, it's fine fine to build form
ports (although I would be careful with "official" because everything is
pushing towards packages), but if you choose to build from source, you
are choosing to also build the build dependencies.  That's not something
you have to do.  I would actually say that complaining about known
consequences of an conscious decision is unreasonable.

by the way, packages *are* favoured.  That's been the case for a while.



In my case it's just a preference to build everything locally.


so the cost for this preference is extra time and extra building.
That's fine.  The build dependencies are not installed.  Obtaining synth
from building on /usr/ports works too, but then the build dependencies
*are* installed.  So using a provided package would be the better way to
avoid the extra installations.



There is no need to address it, because of two quite different use cases.
As far as I can see synth is excellent in some cases, my point is that
portmaster is fine in some other ones.


I did want to point out that there are many known bugs and open reports,
so it's not "fine" for everyone.  You've apparently not hit them so
that's great for you.

Actually, I don't care what you use, but the using build dependencies as
a justification for not using it and labelling it "unreasonable" at the
same time, I just wanted that expanded on.  I don't know if you still
think it's unreasonable, 

Re: Removing documentation

[Royce Williams]

IMO, this entire thread is masking a deeper symptom: FreeBSD
ports/packages management is fragmented.

Each unofficial tool treats some symptoms well, and others poorly.
The fact that I have to use the phrase "ports/packages" is indicative
of a deep schizophrenia.

Don't get me wrong -- I love the flexibility of choosing a package or
a port.  And I'm all for having choices.  But people should not be
choosing ways to manage core software management functions.

Ideally, users could choose among different UIs/wrappers around the
core of a port/package management system.  The things that each tool
has to do -- the database of current installs, dependency management,
etc. -- should not be reinvented by each tool.  They should be shared
infrastructure that is part of the OS (like Debian's dpkg/apt system).

A unified framework:

* would make it easy for small-scale admins to install basic packages
with sane defaults

* would resolve dependencies sanely

* would allow software maintainers to capture the manual steps
currently stored in /usr/ports/UPDATING, and apply them in an
automated/guided fashion

* would support building and distributing your own packages

* would be part of the base OS and documented accordingly


Until this fragmentation is resolved , we'll be having this discussion
every few months, users will keep shooting themselves in the foot ...
and keep being incented to go elsewhere.

We need to capture users' reasons for preferring specific frameworks,
and build a roadmap to how they could be unified.

Royce
___
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: Removing documentation

[Warren Block]

On Tue, 9 Feb 2016, Jim Ohlstein wrote:

The build time of "like 20-30 minutes, at most" is ummm... let' just call it 
optimistic. I only needed five new dependencies. Poudriere was unable to take 
advantage of more than two parallel builders except for a rather short 
overlap where it used three, if I recall correctly. The vast majority of the 
time it used only one builder. Build and package time for gcc6-aux was 34:52 
on an Intel E5-2650 v3. Build and package time for binutils, required for 
gcc6-aux, took 4:44. That's pretty close to 40 minutes for just two 
dependencies, one of which is a dependency of the other. Build and package 
time for synth was 1:09.


2:20, that's two hours and twenty minutes, to build and install here on 
an Atom N270 system.  2:06 for gcc6-aux, most of the rest for ncurses. 
That does not include distfile download time.  Disk space used was 252M, 
again not counting the distfiles.  For x86, the Atom is nearly 
worst-case, but I suspect the speed is similar to some of the ARM 
systems.


I tried to build it last night on a fast i7 system for comparison, but 
gcc6-aux had a build error at the very start.

___
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: Removing documentation

[William A. Mahaffey III]

On 02/09/16 09:56, Royce Williams wrote:

IMO, this entire thread is masking a deeper symptom: FreeBSD
ports/packages management is fragmented.

Each unofficial tool treats some symptoms well, and others poorly.
The fact that I have to use the phrase "ports/packages" is indicative
of a deep schizophrenia.

Don't get me wrong -- I love the flexibility of choosing a package or
a port.  And I'm all for having choices.  But people should not be
choosing ways to manage core software management functions.

Ideally, users could choose among different UIs/wrappers around the
core of a port/package management system.  The things that each tool
has to do -- the database of current installs, dependency management,
etc. -- should not be reinvented by each tool.  They should be shared
infrastructure that is part of the OS (like Debian's dpkg/apt system).

A unified framework:

* would make it easy for small-scale admins to install basic packages
with sane defaults

* would resolve dependencies sanely

* would allow software maintainers to capture the manual steps
currently stored in /usr/ports/UPDATING, and apply them in an
automated/guided fashion

* would support building and distributing your own packages

* would be part of the base OS and documented accordingly


Until this fragmentation is resolved , we'll be having this discussion
every few months, users will keep shooting themselves in the foot ...
and keep being incented to go elsewhere.

We need to capture users' reasons for preferring specific frameworks,
and build a roadmap to how they could be unified.

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



*Huzzah*  I hereby 2nd that motion (from the cheap seats) :-) 


--

William A. Mahaffey III

 --

"The M1 Garand is without doubt the finest implement of war
 ever devised by man."
   -- Gen. George S. Patton Jr.

___
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: Removing documentation

[Royce Williams]

On Tue, Feb 9, 2016 at 6:50 AM, Royce Williams  wrote:
> IMO, this entire thread is masking a deeper symptom: FreeBSD
> ports/packages management is fragmented.

[snip]

> We need to capture users' reasons for preferring specific frameworks,
> and build a roadmap to how they could be unified.

Anticipating the two perennial objections:


1. "If it's a problem, go ahead and fix it yourself."

There is a spectrum of things that OSes need to do. Software
management is at the "should be managed closely by the core team" end
of the spectrum.

There are some medical emergencies so urgent that the doctors should
stop saying "go to medical school and treat it yourself" and help the
patient.


2. "It's working fine the way it is."

I couldn't disagree more.

Debian/Ubuntu took off because Ian Murdoch realized that the Linux
distros were reinventing the software management wheel poorly -- and
he fixed it.  He did this by building a way to cache and distribute
the dependency wisdom that developers already had in their heads.

In other words, he automated /usr/ports/UPDATING.

Imagine if we could do this.  imagine the power of building on the
great work already done with pkg, and extending and merging it with
portmaster/portupgrade/etc and poudriere.

Imagine how many thousands of developer and users hours -- including
our own -- would be freed up to grow FreeBSD in other ways.

The longer we go without bringing software management into the core,
the harder it's going to get.  But if we cooperate now to combine
binary package management (pkg) with local configuration options
(ports), FreeBSD could take off like Debian did.  People would beat a
path to our door.

I have believed for years that this is the single most important
project that the FreeBSD Foundation could sponsor.  It is the largest
force multiplier we can apply.

Royce
___
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: Removing documentation

[John Marino]

On 2/9/2016 5:00 PM, Warren Block wrote:
> 2:20, that's two hours and twenty minutes, to build and install here on
> an Atom N270 system.  2:06 for gcc6-aux, most of the rest for ncurses.
> That does not include distfile download time.  Disk space used was 252M,
> again not counting the distfiles.  For x86, the Atom is nearly
> worst-case, but I suspect the speed is similar to some of the ARM systems.

How long does "pkg install synth" take? :)

> I tried to build it last night on a fast i7 system for comparison, but
> gcc6-aux had a build error at the very start.

If you have the build log, I'd like to see it.  Dewayne G. got an error
after overriding CPUTYPE (do you do that too?) and I'm thinking it's
sensitive to CPU and I'd like to know more.

John
___
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: Removing documentation

[Warren Block]

On Tue, 9 Feb 2016, John Marino wrote:


On 2/9/2016 7:20 PM, Warren Block wrote:

If you have the build log, I'd like to see it.  Dewayne G. got an error
after overriding CPUTYPE (do you do that too?) and I'm thinking it's
sensitive to CPU and I'd like to know more.


Yes, I use

CPUTYPE?=core-avx2


What happens when you try to build lang/gcc6-devel ?
Same issue or does it complete?


It builds successfully, in about 40 minutes.
___
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: Removing documentation

[John Marino]

On 2/9/2016 9:20 PM, Warren Block wrote:
> On Tue, 9 Feb 2016, John Marino wrote:
> 
>> On 2/9/2016 7:20 PM, Warren Block wrote:
 If you have the build log, I'd like to see it.  Dewayne G. got an error
 after overriding CPUTYPE (do you do that too?) and I'm thinking it's
 sensitive to CPU and I'd like to know more.
>>>
>>> Yes, I use
>>>
>>> CPUTYPE?=core-avx2
>>
>> What happens when you try to build lang/gcc6-devel ?
>> Same issue or does it complete?
> 
> It builds successfully, in about 40 minutes.

My suspicion is that due to the bootstrap, we'd have two possible options:
A) turn on the full bootstrap which takes the same amount of time as
gcc6-devel does (I'm not sure it will work but there's a chance)
B) I put CPUTYPE=native in the gcc6-aux Makefile

I am inclined towards B.  It works on DragonFly but I need somebody else
to test it on i7 on FreeBSD.  I asked Dewayne, but I'd be grateful if
you could test it as well.

Thanks,
John

___
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: Removing documentation

[Warren Block]

On Tue, 9 Feb 2016, John Marino wrote:


On 2/9/2016 5:00 PM, Warren Block wrote:

2:20, that's two hours and twenty minutes, to build and install here on
an Atom N270 system.  2:06 for gcc6-aux, most of the rest for ncurses.
That does not include distfile download time.  Disk space used was 252M,
again not counting the distfiles.  For x86, the Atom is nearly
worst-case, but I suspect the speed is similar to some of the ARM systems.


How long does "pkg install synth" take? :)


I tried to build it last night on a fast i7 system for comparison, but
gcc6-aux had a build error at the very start.


If you have the build log, I'd like to see it.  Dewayne G. got an error
after overriding CPUTYPE (do you do that too?) and I'm thinking it's
sensitive to CPU and I'd like to know more.


Yes, I use

CPUTYPE?=core-avx2

...
touch stamp-noasandir
if [ x"-fpic" != x ]; then \
  /usr/ports/lang/gcc6-aux/work/bootstrap/bin/gcc -c -DHAVE_CONFIG_H -O2 
-pipe -march=core-avx2  -DLIBICONV_PLUG -fstack-protector 
-fno-strict-aliasing -I/usr/local/include -DLIBICONV_PLUG -I. 
-I/usr/ports/lang/gcc6-aux/work/gcc-6-20160124/libiberty/../include  -W 
-Wall -Wwrite-strings -Wc++-compat -Wstrict-prototypes -pedantic 
-D_GNU_SOURCE -fpic 
/usr/ports/lang/gcc6-aux/work/gcc-6-20160124/libiberty/regex.c -o 
pic/regex.o; \

else true; fi
{standard input}: Assembler messages:
{standard input}:42: Error: no such instruction: `shlx %ecx,%esi,%esi'
{standard input}:60: Error: no such instruction: `shlx %ecx,%esi,%esi'
{standard input}:2005: Error: no such instruction: `sarx %edi,%esi,%esi'
{standard input}:3102: Error: no such instruction: `andn %esi,%eax,%esi'
{standard input}:5789: Error: no such instruction: `shlx %esi,%edx,%edx'
{standard input}:5872: Error: no such instruction: `shlx %esi,%edx,%edx'
{standard input}:5962: Error: no such instruction: `shlx %esi,%ecx,%ecx'
{standard input}:6019: Error: no such instruction: `shlx %ecx,%edx,%edx'
{standard input}:6474: Error: no such instruction: `shlx %edx,%edi,%edx'
{standard input}:6517: Error: no such instruction: `shlx %edx,%edi,%edx'
{standard input}:6560: Error: no such instruction: `shlx %edx,%edi,%edx'
{standard input}:6585: Error: no such instruction: `shlx %edx,%edi,%edx'
Makefile:1166: recipe for target 'regex.o' failed
gmake[4]: *** [regex.o] Error 1
gmake[4]: Leaving directory 
'/usr/ports/lang/gcc6-aux/work/build/libiberty'

Makefile:7456: recipe for target 'all-libiberty' failed
gmake[3]: *** [all-libiberty] Error 2
gmake[3]: Leaving directory '/usr/ports/lang/gcc6-aux/work/build'
Makefile:873: recipe for target 'all' failed
gmake[2]: *** [all] Error 2
gmake[2]: Leaving directory '/usr/ports/lang/gcc6-aux/work/build'
*** Error code 2

Stop.
make[1]: stopped in /usr/ports/lang/gcc6-aux
*** Error code 1

Stop.
make: stopped in /usr/ports/lang/gcc6-aux

___
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: Removing documentation

[Jung-uk Kim]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 02/ 9/16 01:20 PM, Warren Block wrote:
> On Tue, 9 Feb 2016, John Marino wrote:
> 
>> On 2/9/2016 5:00 PM, Warren Block wrote:
>>> 2:20, that's two hours and twenty minutes, to build and install
>>> here on an Atom N270 system.  2:06 for gcc6-aux, most of the
>>> rest for ncurses. That does not include distfile download time.
>>> Disk space used was 252M, again not counting the distfiles.
>>> For x86, the Atom is nearly worst-case, but I suspect the speed
>>> is similar to some of the ARM systems.
>> 
>> How long does "pkg install synth" take? :)
>> 
>>> I tried to build it last night on a fast i7 system for
>>> comparison, but gcc6-aux had a build error at the very start.
>> 
>> If you have the build log, I'd like to see it.  Dewayne G. got an
>> error after overriding CPUTYPE (do you do that too?) and I'm
>> thinking it's sensitive to CPU and I'd like to know more.
> 
> Yes, I use
> 
> CPUTYPE?=core-avx2
> 
> ... touch stamp-noasandir if [ x"-fpic" != x ]; then \ 
> /usr/ports/lang/gcc6-aux/work/bootstrap/bin/gcc -c -DHAVE_CONFIG_H
> -O2 -pipe -march=core-avx2  -DLIBICONV_PLUG -fstack-protector 
> -fno-strict-aliasing -I/usr/local/include -DLIBICONV_PLUG -I. 
> -I/usr/ports/lang/gcc6-aux/work/gcc-6-20160124/libiberty/../include
> -W -Wall -Wwrite-strings -Wc++-compat -Wstrict-prototypes
> -pedantic -D_GNU_SOURCE -fpic 
> /usr/ports/lang/gcc6-aux/work/gcc-6-20160124/libiberty/regex.c -o 
> pic/regex.o; \ else true; fi {standard input}: Assembler messages: 
> {standard input}:42: Error: no such instruction: `shlx
> %ecx,%esi,%esi' {standard input}:60: Error: no such instruction:
> `shlx %ecx,%esi,%esi' {standard input}:2005: Error: no such
> instruction: `sarx %edi,%esi,%esi' {standard input}:3102: Error: no
> such instruction: `andn %esi,%eax,%esi' {standard input}:5789:
> Error: no such instruction: `shlx %esi,%edx,%edx' {standard
> input}:5872: Error: no such instruction: `shlx %esi,%edx,%edx' 
> {standard input}:5962: Error: no such instruction: `shlx
> %esi,%ecx,%ecx' {standard input}:6019: Error: no such instruction:
> `shlx %ecx,%edx,%edx' {standard input}:6474: Error: no such
> instruction: `shlx %edx,%edi,%edx' {standard input}:6517: Error: no
> such instruction: `shlx %edx,%edi,%edx' {standard input}:6560:
> Error: no such instruction: `shlx %edx,%edi,%edx' {standard
> input}:6585: Error: no such instruction: `shlx %edx,%edi,%edx'
...

FYI, I had similar problems with bdver2.  I believe it was different
instructions, though.

Jung-uk Kim
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQEcBAEBCAAGBQJWujArAAoJEHyflib82/FG+joH/Rs8ROYbGWGbTtOfzHPlXwcr
G+1fZqLAQzHA32YHfGC/eIk2l5y8A2vCvrRFC0oC4Jz/gs6tVbOqSCIHTJPsExhP
iecN7mXCAXcc8OqCLOBrOICY5i8UDv+NcFPKpgvIO6icIf606s2cIjcICPMF+2YN
zi/Nua3gcS5FOTl4et7mRbkkDH32BNHI3eqngfoToLyaqTMHXsSg8GhvS+cxGnnA
jU7Nvtdzx32owvBLIOdmtEFRGMLYLqLyDV6OEEOKu7/ejltrm9XSoI72S6X1rB2g
VYmhRd3MnWWpc78Lkx87mH03jMJjlWQfjXL70PRb7uP3vpKqBxAsuwVSKe3QAm4=
=Dyn/
-END PGP SIGNATURE-
___
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: maintaining portmaster ? was: Re: Removing documentation

[Peter Jeremy]

On 2016-Feb-09 21:24:56 +0100, Kurt Jaeger  wrote:
>Torsten wrote:
>
>> I did take a look. I could do both: maintaining the port and maintaining 
>> the software. What do you need? ;)
>
>Submit patches to the 12 PRs open for portmaster:
>
>https://bugs.freebsd.org/bugzilla/buglist.cgi?quicksearch=portmaster

That is just being silly.

I'd start by triaging those bugs.  One is clearly a kernel bug,
another maybe a bug in a different port and one is described as a
feature request.  The remaining 9 may or may not still be bugs in
portmaster that are still relevant.  Providing a patch for one of
the bugs would probably be sufficient for demonstrating interest
and ability.

-- 
Peter Jeremy


signature.asc
Description: PGP signature