PRs ready for commit for www/node*
Howdy! I've got several patches pending for the www/node* ports (I'm the maintainer for these ports). One is a fix for several build failures that have been recently reported, one is to fix portlint warnings, and the others are version bumps to address security issues. Build fix: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=210618 portlint fix: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=210619 Version bumps: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=210518 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=210519 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=210520 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=210521 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=210522 I'd appreciate help from a willing and able committer to get these in the tree, ideally before the next quarterly branch is cut. Thanks in advance! :) -- Bradley T. Hughes bradleythug...@fastmail.fm ___ 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: blanket portmgr approval vs. non-fixing changes
Baptiste Daroussin wrote: On Tue, Jun 28, 2016 at 11:15:56PM +0200, Matthias Andree wrote: And I do think we should, opposite to what you are proposing, make the committer spend extra time for high-profile ports that entail sweeping changes to chase down the breaking change to, say, a library port. I might have been not explicit enough, of course any changes should be tested, and of course high profile ports breaking means special attention and prevent the sweeping change to actually happen. Sorry I think you're wrong at this point. Define "high profile" ... Some library port that other obscure ports are dependent on..? What say postgresql94-client or perhaps p5-Bucardo... something that only a few ports (if any) rely on, yet would be a massive problem for a lot of production servers/services if they were suddenly and quietly broken... It's an all or nothing thing, you either ensure your sweeping changes don't break anything, or don't care about anything and just put out an announcement that you made the change. Selecting some random list of what you consider should not be broken (or should be fixed first) based on some random list of what you think is important is a short sighted and unprofessional methodology as it creates more uncertainty and confusion.. My opinion, feel free to ignore as usual. -- 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"
FreeBSD ports you maintain which are out of date
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 +-+ chinese/tin | 2.3.3 | 2.3.4 +-+ multimedia/flvtool++| 1.2.1 | 1.2.1-1 +-+ If any of the above results are invalid, please check the following page for details on how to improve portscout's detection and selection of distfiles on a per-port basis: http://portscout.freebsd.org/info/portscout-portconfig.txt Thanks. ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: blanket portmgr approval vs. non-fixing changes
+--On 29 juin 2016 13:15:44 +0200 Michelle Sullivan wrote: | Baptiste Daroussin wrote: |> On Tue, Jun 28, 2016 at 11:15:56PM +0200, Matthias Andree wrote: |>> |>> And I do think we should, opposite to what you are proposing, make the |>> committer spend extra time for high-profile ports that entail sweeping |>> changes to chase down the breaking change to, say, a library port. |>> |> I might have been not explicit enough, of course any changes should be |> tested, and of course high profile ports breaking means special |> attention and prevent the sweeping change to actually happen. |> | Sorry I think you're wrong at this point. | | Define "high profile" ... Some library port that other obscure ports are | dependent on..? What say postgresql94-client or perhaps p5-Bucardo... | something that only a few ports (if any) rely on, yet would be a massive | problem for a lot of production servers/services if they were suddenly | and quietly broken... High profile is gmake, gettext, or libpng, those important things. -- Mathieu Arnold pgpTEx9XWiGbt.pgp Description: PGP signature
Re: blanket portmgr approval vs. non-fixing changes
Mathieu Arnold wrote: +--On 29 juin 2016 13:15:44 +0200 Michelle Sullivan wrote: | Baptiste Daroussin wrote: |> On Tue, Jun 28, 2016 at 11:15:56PM +0200, Matthias Andree wrote: |>> |>> And I do think we should, opposite to what you are proposing, make the |>> committer spend extra time for high-profile ports that entail sweeping |>> changes to chase down the breaking change to, say, a library port. |>> |> I might have been not explicit enough, of course any changes should be |> tested, and of course high profile ports breaking means special |> attention and prevent the sweeping change to actually happen. |> | Sorry I think you're wrong at this point. | | Define "high profile" ... Some library port that other obscure ports are | dependent on..? What say postgresql94-client or perhaps p5-Bucardo... | something that only a few ports (if any) rely on, yet would be a massive | problem for a lot of production servers/services if they were suddenly | and quietly broken... High profile is gmake, gettext, or libpng, those important things. No disrespect intended, however... gettext-runtime sure 100% with you... gettext-devel ...? gmake? (break gmake it stops people compiling lots, but doesn't actually break production servers) libpng ... 50/50 on that .. its sorta like postgres*-* I have servers that don't have libpng, and I have servers that don't.. ...but that's sort of my point... it really should be an all or nothing thing... and IMHO it should be 'all'... Bulk changes in my opinion should not leave something that was working, not working. 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"
audio/csound6 endless loop and creates empty sound files
Hello, has anyone used audio/csound6 recently on FreeBSD? It compiles just fine, but it creates bogus output, AFAICS. Here's an example, simplified from Chapter 1 of The CSound Book: http://www.csounds.com/chapter1/ $ cat e1.orc sr = 44100 kr = 4410 ksmps = 10 nchnls = 1 instr 101 a1 oscil 1, 440, 1 out a1 endin $ cat e1.sco ; Function 1 uses the GEN10 subroutine to compute a sine wave f 10 4096 10 1 ;inst start duration i 101 0 3 Running "csound e1.orc e1.sco" on Linux would create a file "test.wav" with a 440 Hz tone that can be rendered with any program like mplayer, vlc, etc... It would also display a sine wave as text. On FreeBSD, csound just runs in an endless loop, and test.wav grows and grows. If I stop csound with Ctrl-C, and inspect test.wav with hd(1), there's a header, followed by 00-bytes; that's all. I can vary the output format, it doesn't matter: always 00 samples are being output in an endless loop: $ csound e1.orc e1.sco virtual_keyboard real time MIDI plugin for Csound 0dBFS level = 32768.0 Csound version 6.06 (double samples) Jun 29 2016 libsndfile-1.0.26 orchname: e1.orc Elapsed time at end of orchestra compile: real: 0.004s, CPU: 0.000s sorting score ... ... done Elapsed time at end of score sort: real: 0.004s, CPU: 0.000s --Csound version 6.06 (double samples) Jun 29 2016 graphics suppressed, ascii substituted 0dBFS level = 32768.0 orch now loaded audio buffered in 256 sample-frame blocks writing 512-byte blks of shorts to test.wav (WAV) SECTION 1: ^C csound command: Interrupt csoundPerform(): stopped. inactive allocs returned to freespace end of score. overall amps: 0.0 overall samples out of range:0 0 errors in performance Elapsed time at end of performance: real: 9.596s, CPU: 9.539s 256 512 sample blks of shorts written to test.wav (WAV) $ ls -l test.wav -rw-r--r-- 1 cpghost users 221763644 Jun 29 18:35 test.wav $ hd test.wav 52 49 46 46 34 d8 37 0d 57 41 56 45 66 6d 74 20 |RIFF4.7.WAVEfmt | 0010 10 00 00 00 01 00 01 00 44 ac 00 00 88 58 01 00 |DX..| 0020 02 00 10 00 64 61 74 61 10 d8 37 0d 00 00 00 00 |data..7.| 0030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 || * 0d37d830 Needless to say that this output file plays silent. So, there's something definitively broken in audio/csound6, because this happens ONLY on FreeBSD, not on Linux. More details on the port: $ uname -a FreeBSD phenom.fritz.box 10.3-STABLE FreeBSD 10.3-STABLE #0 r299381: Tue May 10 21:34:52 CEST 2016 r...@phenom.fritz.box:/usr/obj/usr/src/sys/GENERIC amd64 $ cat /var/db/ports/audio_csound6/options # This file is auto-generated by 'make config'. # Options for csound6-6.06_1 _OPTIONS_READ=csound6-6.06_1 _FILE_COMPLETE_OPTIONS_LIST=ALSA CURL DSSI FLTK FLUIDSYNTH HDF5 JACK LUA NLS OPENMP OSC PNG PORTAUDIO PULSEAUDIO OPTIONS_FILE_UNSET+=ALSA OPTIONS_FILE_SET+=CURL OPTIONS_FILE_SET+=DSSI OPTIONS_FILE_SET+=FLTK OPTIONS_FILE_SET+=FLUIDSYNTH OPTIONS_FILE_SET+=HDF5 OPTIONS_FILE_UNSET+=JACK OPTIONS_FILE_SET+=LUA OPTIONS_FILE_SET+=NLS OPTIONS_FILE_SET+=OPENMP OPTIONS_FILE_SET+=OSC OPTIONS_FILE_SET+=PNG OPTIONS_FILE_UNSET+=PORTAUDIO OPTIONS_FILE_SET+=PULSEAUDIO I've tried various options, and recompiled audio/libsndfile too, but still couldn't get csound6 to work correctly. Any advice? Thanks, -cpghost. -- Cordula's Web. http://www.cordula.ws/ ___ 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: blanket portmgr approval vs. non-fixing changes
On Wed, Jun 29, 2016 at 06:35:46PM +0200, Michelle Sullivan wrote: > Mathieu Arnold wrote: > > +--On 29 juin 2016 13:15:44 +0200 Michelle Sullivan > > wrote: > > | Baptiste Daroussin wrote: > > |> On Tue, Jun 28, 2016 at 11:15:56PM +0200, Matthias Andree wrote: > > |>> > > |>> And I do think we should, opposite to what you are proposing, make the > > |>> committer spend extra time for high-profile ports that entail sweeping > > |>> changes to chase down the breaking change to, say, a library port. > > |>> > > |> I might have been not explicit enough, of course any changes should be > > |> tested, and of course high profile ports breaking means special > > |> attention and prevent the sweeping change to actually happen. > > |> > > | Sorry I think you're wrong at this point. > > | > > | Define "high profile" ... Some library port that other obscure ports are > > | dependent on..? What say postgresql94-client or perhaps p5-Bucardo... > > | something that only a few ports (if any) rely on, yet would be a massive > > | problem for a lot of production servers/services if they were suddenly > > | and quietly broken... > > > > High profile is gmake, gettext, or libpng, those important things. > > > No disrespect intended, however... > > gettext-runtime sure 100% with you... gettext-devel ...? > gmake? (break gmake it stops people compiling lots, but doesn't actually > break production servers) > libpng ... 50/50 on that .. its sorta like postgres*-* I have servers that > don't have libpng, and I have servers that don't.. > > ...but that's sort of my point... it really should be an all or nothing > thing... and IMHO it should be 'all'... Bulk changes in my opinion should > not leave something that was working, not working. > > Regards, In theory yes, but in reality how to you handle texinfo update have breaking the syntax and leaving 10 ports are not dependency on and have not been updated upstream for around 15 years? (Yeah I have been through that and actually fixed 8 of those and left the 2 others because I really could no find the fix and actually noone complained and this was more than 2 years ago). of a lib like let say libpng which have a security issue moving you do newer version of the lib which of course because how stable libpng API is you end up having to fix 250 ports and you end up with 3 ports you cannot update because over complicated code and those ports have not been maintained for more than 10 years... you mark those 2 ports as broken and deprecate them. What about upgrading ruby to the officially commanded version but then you discover puppet37 is broken and upstream claims they don't care and won't ever fix? you end up with marking it as broken and the one who care about puppet37 (which was my case) then you come up and propose a fix and save the ports That is all this is about, of course we expect each committer to aim at 100% of non breakage when you do changes but the reality is always a bit different. and yes if 2 leaf ports are marked as broken in the battle they so be it. We have more than 26k ports in the ports tree. Which is way more than any other operaring system I am aware of, on this list there are around 10-15% of them which are things without any active upstream, often written in old version of C/C++ which breaks on regular basis after libc/toolchain updates and we often manage to make survive (see the getline/dprintf fixes I have been committing recently for exemple). The number of working port 'percentage of the entire ports tree' have never been so high on the entire ports tree since the last 8 years at least (I haven't made any statistics before) since the blanket, the overwhole general quality has improved a lot, resulting in less breakage in the ports tree than what it was before. If one really want to get numbers I can provide numbers about what was the number of failing ports with the default options (which is supposed to be the most tested) 8 years ago, 6 years ago, 2 years ago and now. I have the same numbes with non default options but use on regular basis options like NLS off or DOCS off. We cannot write down a rule that is supposed to describe what is just "common sense" but again my initial message was: yes of course we do aim at 0 breakages on changes, and yes sometime sweep changes leads into marking as broken 2 ports. Pushing sweep changes to be 100% free of breakage leads to people being scared about doing some important modification that are really needed for a while. Look at the history of boost updates for example or ICU... After how long someone really had a look at the bugs from libtool we were suffering for like forever because of overlinking for example - not only - (leading to constant breakage of inplace building) etc. If I only take the freebsd 10 amd64 packages on last run we only got: 13 package build failure over 26k leading to 93 skipped packages on the quarterly branch and only 11 on the head branch of the ports tree leading t
Re: Torch7 ports (Was: Wxlua / Zbstudio)
Hi all, I tried the Jan's git ports. However, I got 21 errors out of 127 torch tests. It said FFI can't point to some structures. Also, I can require nn even it was installed via luarocks. It said the tester suite is missing. Are the blas finding codes located at math/TH? Thanks. Raymond On Jun 24, 2016 17:12, "Raymond Cheung" wrote: > Hi Jan and Torsten, > > Thanks a lot for your help. > > I will try it later after taking a break. As I lack knowledge on C/C++, I > spent a month to retry many ways on FreeBSD 10/11. I feel tried. > Fortunately, I got some clues. > > During this month, I also learnt a lot on FreeBSD. As least I can build > and install new world/kernel from GhostBSD 10.3 to 11 Alpha 4. > > Thanks again for your help. > > Raymond > On Jun 24, 2016 06:41, "Jan Beich" wrote: > >> Torsten Zuehlsdorff writes: >> >> > Hello Raymond, >> > >> >> OpenBlas (make config; # with OpenMP option), OpenMP, Lapack & ++, >> GotoBlas >> >> are installed. Header files of OpenBlas is also included to >> >> $CMAKE_LIBRARY_PATH. However, I still got the same error message, >> missing >> >> lapack. >> > >> > There are various variables to set to specify where to look vor the >> > libs, like lapack. >> > >> > Sadly i'm out of time. Tomorrow i'm heading into vacation. When back i >> > will come back to your request and try to create a port for >> > this. Maybe we could success together (with more time). >> >> I did some work in the past on Torch7 ports before losing interest[1]. >> Check math/TH if you want to see how it detects OpenBLAS (default). >> >> $ git clone https://github.com/jbeich/freebsd-ports torch-ports >> $ export PORTSDIR=$PWD/torch-ports >> $ cd $PORTSDIR/devel/lua-trepl >> $ make install >> $ th51 >> >> -- >> [1] Many Torch pkgs rely on luarocks to build and resolve dependencies >> and some have a hard dependency on luajit. My approach didn't scale >> as writing such ports often required translating *.rockspec files >> which can quickly grow into maintenance nightmare, so an infra work >> had to be done beforehand. >> > ___ 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"
python 3.4.5 update
Hi! I tried to update Python on my 10.3-RELEASE-p5 (akd64) and I got: ports/lang/python34/work/Python-3.4.5 ./python -E -m ensurepip $ensurepip --root=/usr/ports/lang/python34/work/stage/ ; fi /bin/rm -f /usr/ports/lang/python34/work/stage/usr/local/lib/libpython3.so # Upstream Issue: http://bugs.python.org/issue17975 for i in /usr/ports/lang/python34/work/stage/usr/local/lib/python3.4/lib- dynload/*.so; do /usr/bin/strip $i; done # Strip shared extensions > Compressing man pages (compress-man) ===>>> Creating a backup package for old version python34-3.4.4_3 Creating package for python34-3.4.4_3 process with pid 2056 still holds the lock process with pid 2056 still holds the lock process with pid 2056 still holds the lock process with pid 2056 still holds the lock process with pid 2056 still holds the lock process with pid 2056 still holds the lock pkg: Cannot get an advisory lock on a database, it is locked by another process ===>>> Starting check for runtime dependencies ===>>> Gathering dependency list for lang/python34 from ports ===>>> Dependency check complete for lang/python34 ===>>> All >> python34-3.4.4_3 (1/1) ===> Installing for python34-3.4.5 ===> Checking if python34 already installed ===> An older version of python34 is already installed (python34- 3.4.4_3) You may wish to ``make deinstall'' and install this port again by ``make reinstall'' to upgrade it properly. If you really wish to overwrite the old port of python34 without deleting it first, set the variable "FORCE_PKG_REGISTER" in your environment or the "make install" command line. *** Error code 1 Stop. make[1]: stopped in /usr/ports/lang/python34 *** Error code 1 Stop. make: stopped in /usr/ports/lang/python34 ===>>> A backup package for python34-3.4.4_3 should be located in /usr/ports/packages/portmaster-backup ===>>> Installation of python34-3.4.5 (lang/python34) failed ===>>> Aborting update ===>>> Update for lang/python34 failed ===>>> Aborting update Thank you very much. SK ___ 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: Is there still broken lang/ruby23 ?
Hi,
> On Tue, 28 Jun 2016 22:13:44 -0400
> Steve Wills said:
Kazuhiko> Is there still broken lang/ruby23[1]. Or can build in latest
Kazuhiko> 11.0-* ?
Kazuhiko> [1]
http://permalink.gmane.org/gmane.os.freebsd.devel.pkg-fallout/294364
swills> Yes, I haven't looked at it yet, but if you want to take a look, I'd
swills> welcome patches.
Could you put the attached two patches into lang/ruby23/files and give
it a try?
--- ccan/list/list.h.orig 2015-09-06 07:10:54 UTC
+++ ccan/list/list.h
@@ -57,7 +57,7 @@ struct list_head
* Example:
* static struct list_head my_list = LIST_HEAD_INIT(my_list);
*/
-#define LIST_HEAD_INIT(name) { { &name.n, &name.n } }
+#define CCAN_LIST_HEAD_INIT(name) { { &name.n, &name.n } }
/**
* LIST_HEAD - define and initialize an empty list_head
@@ -72,8 +72,8 @@ struct list_head
* Example:
* static LIST_HEAD(my_global_list);
*/
-#define LIST_HEAD(name) \
- struct list_head name = LIST_HEAD_INIT(name)
+#define CCAN_LIST_HEAD(name) \
+ struct list_head name = CCAN_LIST_HEAD_INIT(name)
/**
* list_head_init - initialize a list_head
--- thread_pthread.c.orig 2016-04-15 16:07:07 UTC
+++ thread_pthread.c
@@ -1154,7 +1154,7 @@ native_sleep(rb_thread_t *th, struct tim
}
#ifdef USE_UBF_LIST
-static LIST_HEAD(ubf_list_head);
+static CCAN_LIST_HEAD(ubf_list_head);
/* The thread 'th' is registered to be trying unblock. */
static void
--
Hajimu UMEMOTO
u...@mahoroba.org u...@freebsd.org
http://www.mahoroba.org/~ume/
___
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: PRs ready for commit for www/node*
Hi! > I've got several patches pending for the www/node* ports [...] > I'd appreciate help from a willing and able committer to get these > in the tree, ideally before the next quarterly branch is cut. Done. -- 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: PRs ready for commit for www/node*
> On 30 Jun 2016, at 08:28, Kurt Jaeger wrote: > > Hi! > >> I've got several patches pending for the www/node* ports [...] > >> I'd appreciate help from a willing and able committer to get these >> in the tree, ideally before the next quarterly branch is cut. > > Done. Thanks, Kurt. I appreciate it :) -- Bradley T. Hughes bradleythug...@fastmail.fm ___ 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"
