Re: Porters Handbook section 4.4

[Benjamin Kaduk]

On Thu, Oct 26, 2017 at 08:26:21PM -0700, Russell Haley wrote:
> Hello,
> 
> I'm still stuck building the new chapters I wrote for the Porters
> Handbook. I can't seem to get the system to "find" the file noted in
> my previous post:

Sorry I missed this the first time around.  It would be highly unexpected
if you needed to manually download chunk.xsl from sourceforge, so it may
be best to start off looking at your build environment with pristine sources.
So, maybe snag a fresh copy and don't patch it at all yet.
Do you have the 'docproj' port/package installed already? (textproc/docproj)
Then you should be able to follow the
https://www.freebsd.org/doc/en_US.ISO8859-1/books/fdp-primer/ and
try to get the pristine sources building.

-Ben
___
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: Porters Handbook section 4.4

[Benjamin Kaduk]

On Wed, Oct 11, 2017 at 06:40:20PM -0400, Ernie Luzar wrote:
> 
> Have nothing to add here, but this post peaked my interest about what 
> your talking about.
> 
> What is Phabricator?

Phabricator is a project/software for doing code review of all sorts.
The FreeBSD documentation tree contains a lot of XML file, which can
be treated as code and subjected to pre-commit review as well.

> What is its use in generating doc markup file for handbook changes?

It doesn't help with converting non-marked-up text to XML form, it's
just a convenient place to post a draft patch and be able to make
line-by-line comments on it that are archived in a useful way.

https://www.phacility.com/phabricator/ seems to be the upstream project's
home page.

-Ben
___
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: Porters Handbook section 4.4

[Benjamin Kaduk]

On Wed, Oct 11, 2017 at 11:23:58AM -0700, Russell Haley wrote:
> Here is chapter 1 in an odt since it's a new work and I wanted to bang
> it out without formatting. I'll add it to the sources after I get a
> good start on Chapter 2 and post a patch. I assume phabricator the
> preferred tool for commenting on documents?

No harm in banging it out without formatting (nothing wrong with 
plain-old-UTF-8,
even).

Phabricator is the preferred tool, yes.  It will take me a few days to
have a chance to look, most likely.

Thanks again,

Ben
___
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: Porters Handbook section 4.4

[Benjamin Kaduk]

On Mon, Oct 09, 2017 at 12:22:11AM -0700, Russell Haley wrote:
> On Mon, Oct 2, 2017 at 9:21 AM, Russell Haley  wrote:
> > On Fri, Sep 29, 2017 at 7:58 AM, Warren Block  wrote:
> >> On Mon, 25 Sep 2017, Russell Haley wrote:
> >>
> >>> Thanks! I'll play with this on the weekend.
> >>
> >>
> >> Please create a review at https://reviews.freebsd.org/ and add me as a
> >> reviewer.
> >>
> >> Thanks!
> >
> > Will do. Just a progress update: I got the handbook sources and found
> > the section in chapter.xml. I created a Geany project with everyone's
> > raw notes and the sources. To be continued...

IIRC Warren had volunteered to help get that text committed, but if
not, feel free to add me to the phabricator review when it's ready.

> 
> Hi,
> 
> So I got a good chunk of work done moving koobs’ description into the
> correct format and then started looking at how everything hangs
> together. I don’t want to offend anyone on this list, but I think the
> organisation and some of the English in the first 4 chapters needs
> work. I know how hard it is to create content from nothing (and how
> easy it is to be critical), so my hat is off to the original content

Given how deep a tangle of patchwork and incremental change on top of
incremental change it is, it's unsurprising that the overall organization
of things does not make the best of sense.

> creators. However, what I would like to propose is this:
> 
> 1) Re-write the introduction to describe what the ports system is and
> point to the correct references in the handbook for running ports. I
> would also include reference to how to use subversion (handbook) and
> the correct repository names. I would also point users to websvn. I
> would indicate that the pkg system works off of the ports and include
> some other helpful links such as freshports, github and the build
> system. I would include a paragraph about how bugillza can be searched
> for issues for ports and also describe how phabricator is used to
> submit new patches to the ports system. Finally, it should be
> emphasised that anyone can create a new port for their software and
> submit it to the system.
> 
> 2) The second chapter should be a description of how the ports system
> works. This description can be found in the how things work section of
> chapter 4. Include further description of the make files and where
> they can be found. A note should be made that while the makefiles are
> source code, they are well documented at the top and can be referenced
> when needed for more information. Chapter 2 should describe how
> additional targets can be created (content also from chapter 4).
> 
> 3) Chapter 3 should remain and should be renamed Port Files Overview
> (or something to that effect). The first page should outline the files
> and involved. Most of them are quite simple and dedicating an entire
> ‘section’ to each step is cumbersome. Section 3.1 and 3.2 should be
> combined and beefed up (not sure the name yet). Section 3.3. and 3.4
> should be combined and called Validation and Verification (or
> something to that effect). A description of what portlint does should
> be added. The  new "V" section should describe why testing is
> important and what things to pay attention to, as well as reference
> the do’s and don't s section.
> 
> 4) Chapter 4 should be called adding or updating ports. It should
> briefly describe what should be done to create a new port and then
> describe the processes as outlined by koobs'. The manual porting
> instructions should be removed.
> 
> If there is any interest in me doing this, please speak up now as I
> might be able to take a day off this week and bash it out in one
> sitting. Okay, it's late...

This sounds like a pretty good strategy, especially the part where
we actually introduce the subject matter!

I don't want to tell you to take a day off, but would be happy to
see something like this appear eventually.

Thanks for putting these thoughts together,

Ben
___
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: manpath change for ports ?

[Benjamin Kaduk]

On Thu, Mar 09, 2017 at 12:35:32PM +0100, Tijl Coosemans wrote:
> Note that -rpath /usr/local/lib isn't added by gcc but by libtool
> because it assumes rtld will not search that directory automatically.
> If you run './configure CC=gcc --prefix=/usr && make check' the tests
> should succeed (without --enable-new-dtags) because -rpath isn't used
> then.

Sounds like a bug in the libtool packaging, then?

-Ben
___
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: recent change to vim defaults?

[Benjamin Kaduk]

On Mon, Jan 16, 2017 at 12:03:08AM +0800, Julian Elischer wrote:
> I noticed that suddenly vim is grabbing mouse movements, which makes 
> life really hard.
> 
> Was there a specific revision that brought in this change, and can it 
> be removed?

I remember seeing something go by during an upgrade somewhat recently
about there now being a defaults file that gets used when a user does
not specify a .vimrc.  Unfortunately, I don't remember whether I saw
that notice on a FreeBSD machine or a Debian one, and haven't been able
to find the notice I remember through searching some likely places.

Just to check: do you have a .vimrc file in place already?

-Ben
___
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: shells/bash port, add a knob which symlinks to /bin/bash ?

[Benjamin Kaduk]

On Fri, 12 Sep 2014, Rang, Anton wrote:

  If you want interoperability just use /usr/bin/env bash as a shebang.

 That doesn't work for this use case -- the user shell coming from LDAP
 -- but I agree that the port shouldn't be modifying /usr/bin.

Here at MIT, where our Athena environment has a long history of providing
a consistent experience across many different platforms, we ended up
limiting the login shells a user could select, to a whitelist we provide
(/bin/sh, /usr/athena/bin/bash, and /usr/athena/bin/tcsh).  (The latter
two are now symlinks to the normal system shells, but they used to be
custom binaries.)

Some people did not like being so restricted, and set their login shell to
/bin/sh, with logic in their dotfiles to re-exec a different shell
depending on the current runtime environment.

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

Re: rtld or lang/gcc cannot find libgcc_s.so.1

[Benjamin Kaduk]

On Tue, 21 Feb 2012, Steve Kargl wrote:


On Tue, Feb 21, 2012 at 05:00:53PM -0500, Diane Bruce wrote:

On Tue, Feb 21, 2012 at 10:37:15PM +0100, Dimitry Andric wrote:

On 2012-02-21 20:42, Steve Kargl wrote:
...

Yes, /lib comes before /usr/local/lib/gcc46.  I suppose
that this is a heads up for gerald@. lang/gcc is used by
the ports collections to build a large number of other
ports, so others are likely to hit this issue.


Does -rpath not help ?


I already mentioned that I can add '-rpath /usr/local/lib/gcc46'
to my various projects.  I can also build with -static to avoid
rtld.  One can also use LD_LIBRARY_PATH.

The issue seems to be that lang/gcc will be installed after
system start, and 'ldconfig -m' appends new shared libraries
to the hints file.  This means that libraries with the same
name but different locations will be found via the order of the
search path in the hints file, and one gets the wrong library.
That is, with the following

troutmask:root[256] ldconfig -r | grep libgcc_s
   29:-lgcc_s.1 = /lib/libgcc_s.so.1
   723:-lgcc_s.1 = /usr/local/lib/gcc46/libgcc_s.so.1

29 will be found before 723.  While I can work around the
issue, lang/gcc is used by a rather large boatload of ports
during the building process and I suspect that a large
number of FreeBSD users use lang/gcc for their everyday
compiler.  The question is how do we, the FreeBSD project,
deal with this issue, so that the general user base does not
get hit with it.


I think there is perhaps a little more to this issue of multiple 
(incompatible) copies of a library with the same name being installed, 
e.g. libcom_err in /usr/lib/libcom_err.so and 
/usr/local/lib/libcom_err.so.  An application using the library must 
#include com_err.h to get the library prototypes, but the preprocessor 
puts the standard include search path /usr/include at the end of the 
search list, even if it is specified explicitly on the command line, 
unless -nostdinc is passed. So this will prefer the header from ports in 
the absence of evil trickery.


I was pounding my head against this a couple years ago, so my memory is 
not quite fresh, but I think that I could convince the compile-time link 
step to use either version of the library with the appropriate ordering of 
-L arguments (but I am in trouble if I want libkrb5.so from ports and 
libcom_err.so from base!).


In any case, the dynamic linker will search the default search path 
*first*, preferring the copy of the library from the base system.  After 
pounding my head against the issue for a while I concluded that I had no 
option other than to use -rpath (but alas I ran out of time for that 
particular project and never finished).


It is definitely an ugly situation and I have no good answers.  It would 
be nice to not have to specify every detail of what should be happening, 
though.




There are a few solutions:
1) Set ldconfig_paths in /etc/rc.conf to cause ${PORTSDIR}/lib to
  be scanned before /lib and /usr/lib.
2) Use /etc/ld.so.conf to cause ${PORTSDIR}/lib to be scanned
  for /lib and /usr/lib.
3) Add a new option to ldconfig to prepend new libraries to
  the hints files and fix the ports to use this option instead
  of -m.
4) Suggestions from people that are brighter than I.


How would things break if we made everything in the base system specify 
-rpath of /lib and /usr/lib as appropriate, and then put the ports 
versions first in the default search path?


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

Re: [ECFT] pkgng 0.1-alpha1: a replacement for pkg_install

[Benjamin Kaduk]

On Mon, 28 Mar 2011, Julien Laffaye wrote:


On Mon, Mar 28, 2011 at 6:59 PM, Garrett Cooper gcoo...@freebsd.org wrote:

On Mon, Mar 28, 2011 at 10:44 AM, Andriy Gapon a...@freebsd.org wrote:


II. Package signing.


That would be really nice.


Right know we only planned to sign the repo database, so we can trust
the sah256 of the packages stored in the database. Then if the package
has the same sha256 as the one in the repo database it is considered
trusted.
If we want a per-package signing, we would have a tarball in a tarball.


I really expected this to have been mentioned already, but this approach 
(tarball in a tarball) is taken by Debian packages, and I don't remember 
hearing of any issues related to it.  I don't think it's worth discounting 
from the start without giving some considerationg, but I will defer to the 
people actually doing the work.


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

what to use as source for libss?

[Benjamin Kaduk]

Hi all,

I'm looking to make a port for libss, so that I
can make another port (the zephyr IM library)
that depends on it.  FreeBSD used to have a libss,
but kris removed it 7 years ago because it was not
getting used.
NetBSD still installs a libss, and they use the
source from Heimdal (which is in lib/sl, interestingly enough).
I asked around here at MIT, and people indicated that
the most current version of a libss would be in the
e2fsprogs package, and, in fact, that source package
is used for the Debian libss package.

It seems kind of sad to pull in another tarball when
there is probably somethin good enough in the
base system source, but my understanding is that
we want to keep the ports system useable even when
there is no source present for the base system.

Could someone with more experience than me please
confirm (or contradict) my reasoning that the
e2fsprogs tarball is the right thing to use as a
source package, here?

Thanks,

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