FreeBSD Port: net/adasockets

[yani24enal]

Dikirim dari ponsel cerdas Samsung Galaxy saya.
___
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: Synth and circular dependencies

[Adam Weinberger]

> On 22 Aug, 2017, at 20:11, Thomas Mueller  wrote:
> 
> from Jonathan Chen:
> 
>> On 22 August 2017 at 18:34, Thomas Mueller  wrote:
> [...]
>>> I believe Synth and poudriere have no means for setting options.  That 
>>> should be enough impetus to make it easier to bypass the dialog4ports 
>>> entirely.
> 
>>> From the synth man page:
>> -make.conf
>>   This is an optional, user-provided file. If it exists,
>>   the builder's /etc/make.conf will be appended with the
>>   contents of this file. For the default profile, the
>>   file would normally be located at
>>   /usr/local/etc/synth/LiveSystem-make.conf
> 
>> All you need to do is to convert your /var/db/ports/* options into
>> make.conf style options and put it into LiveSystem-make.conf.
> 
>> Works for me.
> 
> At this stage, I think I don't want to ever again see a dialog4ports!
> 
> How do I convert /var/db/ports/* options into make.conf-style options in a 
> reasonable amount of time?

Make a script. The directory name is the option prefix.

> I don't (yet) have a LiveSystem-make.conf apart from /etc/make.conf, but I 
> have 
> /usr/local/etc/synth/synth.ini
> 
> I see (running "less" on this file)
> 
> [Global Configuration]
> 
> 
> [LiveSystem]
> 
> Directory_packages= /var/synth/live_packages
> Directory_repository= /var/synth/live_packages/All
> Directory_portsdir= /BETA1/usr/ports
> Directory_options= /var/db/ports
> Directory_distfiles= /BETA1/usr/ports/distfiles
> Directory_buildbase= /usr/obj/synth-live
> Directory_logs= /var/log/synth
> Directory_ccache= disabled
> Directory_system= /
> Number_of_builders= 6
> Max_jobs_per_builder= 4
> Tmpfs_workdir= true
> Tmpfs_localbase= true
> Display_with_ncurses= true
> leverage_prebuilt= false
> 
> occurring four times, the latter three being verbatim repeats of the first.
> 
> Now I want to get rid of the Directory_options line, should I delete the line 
> or should I change "/var/db/ports" to "/dev/null"?  Or just move 
> /var/db/ports to /var/db/ports2, which I intend to do anyway?
> 
> What if synth finds /var/db/ports no longer there?

Just move everything out of it. That directory starts off empty anyway.

# Adam


-- 
Adam Weinberger
ad...@adamw.org
https://www.adamw.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: Synth and circular dependencies

[Thomas Mueller]

from Jonathan Chen:

> On 22 August 2017 at 18:34, Thomas Mueller  wrote:
[...]
> > I believe Synth and poudriere have no means for setting options.  That 
> > should be enough impetus to make it easier to bypass the dialog4ports 
> > entirely.

> >From the synth man page:
>  -make.conf
>This is an optional, user-provided file. If it exists,
>the builder's /etc/make.conf will be appended with the
>contents of this file. For the default profile, the
>file would normally be located at
>/usr/local/etc/synth/LiveSystem-make.conf

> All you need to do is to convert your /var/db/ports/* options into
> make.conf style options and put it into LiveSystem-make.conf.

> Works for me.

At this stage, I think I don't want to ever again see a dialog4ports!

How do I convert /var/db/ports/* options into make.conf-style options in a 
reasonable amount of time?

I don't (yet) have a LiveSystem-make.conf apart from /etc/make.conf, but I have 
/usr/local/etc/synth/synth.ini

I see (running "less" on this file)

[Global Configuration]


[LiveSystem]

Directory_packages= /var/synth/live_packages
Directory_repository= /var/synth/live_packages/All
Directory_portsdir= /BETA1/usr/ports
Directory_options= /var/db/ports
Directory_distfiles= /BETA1/usr/ports/distfiles
Directory_buildbase= /usr/obj/synth-live
Directory_logs= /var/log/synth
Directory_ccache= disabled
Directory_system= /
Number_of_builders= 6
Max_jobs_per_builder= 4
Tmpfs_workdir= true
Tmpfs_localbase= true
Display_with_ncurses= true
leverage_prebuilt= false

occurring four times, the latter three being verbatim repeats of the first.

Now I want to get rid of the Directory_options line, should I delete the line 
or should I change "/var/db/ports" to "/dev/null"?  Or just move /var/db/ports 
to /var/db/ports2, which I intend to do anyway?

What if synth finds /var/db/ports no longer there?

Tom

___
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: Synth and circular dependencies

[Jonathan Chen]

On 22 August 2017 at 18:34, Thomas Mueller  wrote:
[...]
> I believe Synth and poudriere have no means for setting options.  That should 
> be enough impetus to make it easier to bypass the dialog4ports entirely.

>From the synth man page:
 -make.conf
   This is an optional, user-provided file. If it exists,
   the builder's /etc/make.conf will be appended with the
   contents of this file. For the default profile, the
   file would normally be located at
   /usr/local/etc/synth/LiveSystem-make.conf

All you need to do is to convert your /var/db/ports/* options into
make.conf style options and put it into LiveSystem-make.conf.

Works for me.
-- 
Jonathan Chen 
___
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: Synth and circular dependencies

[Thomas Mueller]

from RW via freebsd-ports:

> Thomas Mueller wrote:


> > It was very disconcerting when I would do a massive portupgrade
> > before going to bed and subsequently find portupgrade stopped for an
> > options dialog.

> FWIW portupgrade has a -c option to avoid that.

I remember that back from the days when I used portupgrade, and ports system 
used the old dialog.

I wish NetBSD and pkgsrc would port portmaster and/or portupgrade.

Synth and pkgng seem to have fallen into desuetude in pkgsrc. 

Synth won't build on NetBSD because gcc6-aux is broken (Makefile says so), and 
I failed in an attempt to build pkg on NetBSD, but good on FreeBSD ports.

from Don Lewis and my previous post:

> > What is the priority when /var/db/ports is present, which takes
> > precedence?  Should I delete /var/db/ports or /var/db/ports/* ?

> I suspect that /var/db/ports takes priority of options are set in both
> places.  I'd delete it if you move your option settings to make.conf.

> > The ports dialog prior to dialog4ports would always mess the screen
> > whenever I made a log file with tee (just as bad with script).
> > Dialog4ports avoided messing the screen.
>
> > It was very disconcerting when I would do a massive portupgrade before
> > going to bed and subsequently find portupgrade stopped for an options
> > dialog.
 
> I always ran "portupgrade -aFc" beforehand to set the options and also
> fetch all the distfiles.  Some of the ports that I built had distfiles
> that needed to be manually fetched and a fetch failure during the night
> could also be devastating.  Even then there was one port that had its
> own dialog (procmail?) that would sometimes wedge an overnight
> portupgrade run.
 
> > I believe Synth and poudriere have no means for setting options.  That
> > should be enough impetus to make it easier to bypass the dialog4ports
> > entirely.

> The poudriere testport -c option runs make config to pop up the options
> dialog.  It's handy for testing the port's options when doing
> development.  The options settings aren't sticky, though.

> > (NetBSD) pkgsrc has a file options.mk in each package entry where
> > there are options.  One can run "make show-options" and "make
> > show-depends-options" to see options for main package and
> > dependencies.  I like it better than "make showconfig-recursive".
>
> > Now for FreeBSD 11.1-STABLE installation, I will have to redo the
> > options into OPTIONS_SET, etc, and either delete /var/db/ports (a
> > horrible mess now, so nothing to lose) or move it out of the way.
>
> > Another advantage of putting options in make.conf or mk.conf is that
> > the file can be copied or edited from another FreeBSD or NetBSD
> > installation.

> Well, you could copy /var/db/ports over, but ...

If I want to partially convert options from /var/db/ports but keep out of 
harm's way, I could move it to /var/db/ports2 for reference.

Then I could 
make PORT_DBDIR=/var/db/ports2 showconfig-recursive
or from another installation, mounting on /media/zip0,
make PORT_DBDIR=/media/zip0/var/db/ports2 showconfig-recursive

Or I could look directly in /var/db/ports2 files (cumbersome), that would even 
work from NetBSD.

I no longer use traditional BSD disklabels, so, with GPT, FreeBSD and NetBSD 
can read and write each other's ffs/UFS partitions.

Tom

___
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: Question on Amavis and ramdisk

[Willem Jan Withagen]

On 21-8-2017 15:40, RW via freebsd-ports wrote:
> On Mon, 21 Aug 2017 14:47:43 +0200
> Willem Jan Withagen wrote:
> 
>> Hi,
>>
>> In the amavis rc.d file is noted:
>> ""
>> "WARNING: using ramdisk is reported to be unstable and"
>> "thus it is highly recommended to be turned off."
>> ""
>>
>> And this warning seems there since 2012
> 
> 
> 
> Actually it came in with revision 228889 in 2009. The script at
> that point didn't allow for tmpfs and only checks for an existing md
> device before creating a malloc md device (i.e. in unswapable wired
> kernel memory).  IIRC there used to be a warning about this kind of md
> device being able to cause crashes.

Ah, oke,

That I can remember too. But I think that is no longer the case.
Perhaps now with the new rc.d stuff tmpfs is more appropriate.

--WjW


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

Re: r440699 broke xorg on aarch64 (rpi3 and alike)

[Gergely Czuczy]

On 2017. 08. 22. 22:20, Jan Beich wrote:

Gergely Czuczy  writes:


Hello,

r440699 [1] made mesa-dri unconditionally depend on s2tc, which
unconditionally depends on nvidia-texture-tools. nvidia-texture-tools
is not supported on aarch64, which is the platform of rpi3.

Only for `make test`.
And make fetch, fetch-recursive. I just ran into it, while trying to 
start building the xorg images for my rpi3, on a pine64.


I haven't tested other targets, to be honest.

Also, in graphics/nvidia-texture-tools/Makefile this doesn't quite 
suggest the make target restriction:

# see src/nvcore/nvcore.h
ONLY_FOR_ARCHS= amd64 i386 powerpc powerpc64

PS: sorry for the previous private reply, MUA acted up.

Could you please make sure xorg works on aarch64 as well?

http://thunderx1.nyi.freebsd.org/data/latest-per-pkg/xorg-server/1.18.4_3%2C1/110arm64-default.log
http://thunderx1.nyi.freebsd.org/data/latest-per-pkg/xorg-server/1.18.4_3%2C1/head-arm64-default.log


___
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: r440699 broke xorg on aarch64 (rpi3 and alike)

[Jan Beich]

Gergely Czuczy  writes:

> Hello,
>
> r440699 [1] made mesa-dri unconditionally depend on s2tc, which
> unconditionally depends on nvidia-texture-tools. nvidia-texture-tools
> is not supported on aarch64, which is the platform of rpi3.

Only for `make test`.

>
> Could you please make sure xorg works on aarch64 as well?

http://thunderx1.nyi.freebsd.org/data/latest-per-pkg/xorg-server/1.18.4_3%2C1/110arm64-default.log
http://thunderx1.nyi.freebsd.org/data/latest-per-pkg/xorg-server/1.18.4_3%2C1/head-arm64-default.log
___
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"

r440699 broke xorg on aarch64 (rpi3 and alike)

[Gergely Czuczy]

Hello,

r440699 [1] made mesa-dri unconditionally depend on s2tc, which 
unconditionally depends on nvidia-texture-tools. nvidia-texture-tools is 
not supported on aarch64, which is the platform of rpi3.


Could you please make sure xorg works on aarch64 as well? We don't have 
a lot of alternatives on that platform. Making the non-aarch64 
compatible ports optional would be a good start.


Also, let me know if you need a PR for this.

Best regards,
Gergely

[1] https://svnweb.freebsd.org/ports?view=revision=440699


___
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: qemu-aarch64-static

[Jan Beich]

Andrea Venturoli  writes:

> On 08/17/17 21:22, Jan Beich wrote:
>> That page is a bit out of date. Nowadays building for aarch64 is as simple as
>>
>>$ pkg install poudriere qemu-user-static
>>$ service qemu_user_static onestart
>>$ poudriere jail -cj 111aarch64 -a arm64.aarch64 -v 11.1-RELEASE
>>$ poudriere bulk -j 111aarch64 category/port
>
> I can confirm this is working.

To upgrade above jail to native-xtools try

  $ svn co https://svn.freebsd.org/base/releng/11.1 /usr/src
  $ poudriere jail -uj 111aarch64 -x

or create a new jail e.g.,

  $ svn co https://svn.freebsd.org/base/releng/11.1 /usr/src
  $ poudriere jail -cj 111armv6 -x -a arm.armv6 -v releng/11.1 -m svn

>
>> To speed up port builds you may want to consider using native
>> cross-toolchain by creating a jail with -x flag.
>
> Do you have any more info on this?

Nah. native-xtools was briefly mentioned in poudriere-3.1 changelog and
a bit more on EuroBSDCon 2014. I didn't try -x myself until recently.

https://www.youtube.com/watch?v=2J9Lz3pgnbA
https://www.youtube.com/watch?v=JfZIoyQhly4

> Except from poudriere's man page's description I could find no other
> docs. Is there any more elaborate description on what this does and
> how?

poudriere builds native-xtools target under /usr/src, installs it under
/nxb-bin prefix then prepends it via PATH when building ports. For a living
example see armv6 and mips* builders on pkg-status.freebsd.org e.g.,

http://beefy8.nyi.freebsd.org/data/head-armv6-default/p448278_s322683/logs/nasm-2.13.01,1.log

> I built the jail with -x, but how do I check it's using "native-xtools"?

Check /nxb-bin exists and isn't empty e.g.,

  $ file /poudriere/jails/111aarch64/nxb-bin/usr/bin/cc
  /poudriere/jails/111aarch64/nxb-bin/usr/bin/cc: ELF 64-bit LSB executable, 
x86-64, version 1 (FreeBSD), statically linked, for FreeBSD 12.0 (1200040), 
FreeBSD-style, not stripped

  $ /poudriere/jails/111aarch64/nxb-bin/usr/bin/cc -v
  FreeBSD clang version 4.0.0 (tags/RELEASE_400/final 297347) (based on LLVM 
4.0.0)
  Target: aarch64-unknown-freebsd11.1
  Thread model: posix
  InstalledDir: /poudriere/jails/111aarch64/nxb-bin/usr/bin
___
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: qemu-aarch64-static

[Andrea Venturoli]

On 08/22/17 18:03, Luca Pizzamiglio wrote:

yes, the qemu emulation of other architecture means that the CPU is
emulated by software, that's really expensive.
You should consider around 10x slower or even more. ccache can help a
lot in this case.


Thanks.
So you are confirming my poudriere is running an ARM compiler to produce 
ARM code?


What's the use of "-x" when creating a jail then?
What role does the "native cross-toolchain" play?
I understood that would mean running an AMD64 compiler to cross-build 
ARM code... and thought that its timings would be comparable to native 
building.

Is that wrong?

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

Re: Synth and circular dependencies

[Don Lewis]

On 22 Aug, Thomas Mueller wrote:
> from Jonathan Chen:
> 
>> On 22 August 2017 at 15:17, Thomas Mueller
>>  wrote:
> [...]
>> > I really need to be able to see the options in a better way than
>> > the FreeBSD ports framework allows, like in a file /etc/mk.conf
>> > (pkgsrc) or USE= ... as in /etc/make.conf (Gentoo portage).
> 
>> > Dialog4ports is better than the previous dialog but not as good as
>> > seeing in a file mk.conf or make.conf .
> 
>> > Otherwise, I don't really know any elegant way to fix the options
>> > mess I got into.
> 
>> Any reason why don't you can't all your options into /etc/make.conf?
>> I've never used /var/db/ports options as they're not easy to review
>> in one go.
> 
> Going through /var/db/ports is a recipe for insanity.
> 
> from Don Lewis:
> 
>> It is possible to set the options for ports in /etc/make.conf.  That
>> is how I handle it would poudriere which looks for make.conf files in
>> /usr/local/etc/poudriere.d and can use make.conf files that are
>> specific to each jail, ports tree and ports set (poudriere -z option
>> to specify the latter).
> 
>> Specifying the options in make.conf also makes it easier to set
>> options globally for all all of the ports that you build so they are
>> consistent. For instance I specify these options globally:
> 
>> OPTIONS_SET=CUPS APPLET OPENBLAS OBLAS SZIP LETTER GUILE2 GSSAPI_NONE
>> KRB_NONE OPTIONS_UNSET=GUILE1 NETLIB REFERENCE GSSAPI_BASE KRB_BASE
>> KERBEROS
> 
>> Port-specific options can be set like this:
> 
>> graphics_gimp-help_SET=EN
>> graphics_gimp-help_UNSET=ALL
> 
>> Back when I still used portupgrade, I found that dialog4ports got to
>> be really frustrating.
> 
> What is the priority when /var/db/ports is present, which takes
> precedence?  Should I delete /var/db/ports or /var/db/ports/* ?

I suspect that /var/db/ports takes priority of options are set in both
places.  I'd delete it if you move your option settings to make.conf.

> The ports dialog prior to dialog4ports would always mess the screen
> whenever I made a log file with tee (just as bad with script). 
> Dialog4ports avoided messing the screen.
> 
> It was very disconcerting when I would do a massive portupgrade before
> going to bed and subsequently find portupgrade stopped for an options
> dialog.

I always ran "portupgrade -aFc" beforehand to set the options and also
fetch all the distfiles.  Some of the ports that I built had distfiles
that needed to be manually fetched and a fetch failure during the night
could also be devastating.  Even then there was one port that had its
own dialog (procmail?) that would sometimes wedge an overnight
portupgrade run.

> I believe Synth and poudriere have no means for setting options.  That
> should be enough impetus to make it easier to bypass the dialog4ports
> entirely.

The poudriere testport -c option runs make config to pop up the options
dialog.  It's handy for testing the port's options when doing
development.  The options settings aren't sticky, though.

> (NetBSD) pkgsrc has a file options.mk in each package entry where
> there are options.  One can run "make show-options" and "make
> show-depends-options" to see options for main package and
> dependencies.  I like it better than "make showconfig-recursive".
> 
> Now for FreeBSD 11.1-STABLE installation, I will have to redo the
> options into OPTIONS_SET, etc, and either delete /var/db/ports (a
> horrible mess now, so nothing to lose) or move it out of the way.
> 
> Another advantage of putting options in make.conf or mk.conf is that
> the file can be copied or edited from another FreeBSD or NetBSD
> installation.

Well, you could copy /var/db/ports over, but ...

___
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: qemu-aarch64-static

[Luca Pizzamiglio]

yes, the qemu emulation of other architecture means that the CPU is
emulated by software, that's really expensive.
You should consider around 10x slower or even more. ccache can help a
lot in this case.

Best regards,
Luca


On Tue, Aug 22, 2017 at 7:40 AM, Andrea Venturoli  wrote:
> On 08/17/17 21:22, Jan Beich wrote:
>
>> Yep. Link the binary (i.e. "date") statically or run it inside
>> jail/chroot.
>> Otherwise, /libexec/ld-elf.so.1 references the host system, which on amd64
>> wouldn't recognize aarch64 shared libraries.
>
>
> Thanks a lot.
> Now it seems so obvious to me, but I really wouldn't have thought about this
> little detail :)
>
>
>
>> That page is a bit out of date. Nowadays building for aarch64 is as simple
>> as
>>
>>$ pkg install poudriere qemu-user-static
>>$ service qemu_user_static onestart
>>$ poudriere jail -cj 111aarch64 -a arm64.aarch64 -v 11.1-RELEASE
>>$ poudriere bulk -j 111aarch64 category/port
>
>
> I can confirm this is working.
>
>
>
>> To speed up port builds you may want to consider using native
>> cross-toolchain by creating a jail with -x flag.
>
>
> Do you have any more info on this?
> Except from poudriere's man page's description I could find no other docs.
> Is there any more elaborate description on what this does and how?
>
> I built the jail with -x, but how do I check it's using "native-xtools"?
>
> I tried building ports-mgmt/pkg and it requires ten times more than native
> build (i.e. 24 minutes for aarch64 vs. less than 3 minutes for amd64). Is
> this normal?
>
>
>
>  bye & Thanks
> av.
>
> ___
> freebsd-ports@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-ports
> To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
___
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: Synth and circular dependencies

[RW via freebsd-ports]

On Tue, 22 Aug 2017 06:34:15 +
Thomas Mueller wrote:


> It was very disconcerting when I would do a massive portupgrade
> before going to bed and subsequently find portupgrade stopped for an
> options dialog. 

FWIW portupgrade has a -c option to avoid that.
 
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

FreeBSD ports you maintain which are out of date

[portscout]

Dear port maintainer,

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

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

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


Port| Current version | New version
+-+
comms/lirc  | 0.9.0   | 0.10.0
+-+
devel/aws-sdk-cpp   | 1.1.31  | 1.1.32
+-+


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

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

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