MP3 licensing over - can we remove LAME restrictions?
"On April 23, 2017, Technicolor's mp3 licensing program for certain mp3 related patents and software of Technicolor and Fraunhofer IIS has been terminated." http://www.mp3licensing.com/ It seems that the FreeBSD port for LAME could now have the restriction removed, allowing the packages to be available for users by default. Perhaps the LAME option could also be enabled by default in ffmpeg? Thoughts? Regards, Ben -- -- From: Benjamin Woods woods...@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: MP3 licensing over - can we remove LAME restrictions?
On Wed, May 03, 2017 at 07:18:18AM +, Ben Woods wrote: > "On April 23, 2017, Technicolor's mp3 licensing program for certain mp3 > related patents and software of Technicolor and Fraunhofer IIS has been > terminated." > http://www.mp3licensing.com/ > > It seems that the FreeBSD port for LAME could now have the restriction > removed, allowing the packages to be available for users by default. > > Perhaps the LAME option could also be enabled by default in ffmpeg? > > Thoughts? First of all, IMNAL. But I fear that it's not that simple. Even if the program was terminated, it doesn't mean that patents are invalidated. And at least one patent from Fraunhofer IIS is still unexpired: US6185539. Also there is uncertainty about Alcatel's USRE39080. -- Alex ___ 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"
port net/tightvnc failes to build with DEBUG
Hello, when DEBUG is set in /etc/make.conf: CFLAGS+= -DDEBUG the port failes to build with: # make ... rm -f fserve.o cc -c -O2 -pipe -DDEBUG -Wno-return-type -fstack-protector -fno-strict-aliasing -ansi -pedantic -Dasm=__asm -I../../.././/include/fonts -I../include -I../../.././ -I../../.././/exports/include -DCSRG_BASED -DSHAPE -DGCCUSESGAS -DSTATIC_COLOR -DAVOID_GLYPHBLT -DPIXPRIV -D_XSERVER64 -DNDEBUG -DFUNCPROTO=15 -DNARROWPROTOfserve.c fserve.c:412:5: warning: declaration of built-in function 'fprintf' requires inclusion of the header [-Wbuiltin-requires-header] fprintf(stderr, "failed to connect to FS \"%s\"\n", name); ^ fserve.c:412:13: error: use of undeclared identifier 'stderr' fprintf(stderr, "failed to connect to FS \"%s\"\n", name); matthias -- Matthias Apitz, ✉ g...@unixarea.de, ⌂ http://www.unixarea.de/ ☎ +49-176-38902045 ___ 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"
Virtualbox 5.0.26 to 5.1.20/22 problem with upgrade.
i'm asking you because it seems like i'm doing some simple and trivial error. I run 8 VMs with windows 7 with virtualbox 5.0.26. All fine. After upgrading to 5.0.20 or 22 - none of them works. all crashes roughly about the moment it switch from windows loading screen to normal screen. below log from virtualbox that does not show anything useful. VirtualBox VM 5.1.22 r115126 freebsd.amd64 (May 3 2017 12:29:54) release log 00:00:00.312798 Log opened 2017-05-03T10:32:12.883808000Z 00:00:00.312800 Build Type: release 00:00:00.312812 OS Product: FreeBSD 00:00:00.312817 OS Release: 10.0-STABLE 00:00:00.312821 OS Version: FreeBSD 10.0-STABLE #0: Thu Apr 20 18:14:29 CEST 2017 r...@puchar.net:/usr/src/sys/amd64/compile/puchar 00:00:00.312846 Host RAM: 32647MB (31.8GB) total, 984MB available 00:00:00.312851 Executable: /usr/local/lib/virtualbox/VirtualBox 00:00:00.312852 Process ID: 39289 00:00:00.312853 Package type: BSD_64BITS_GENERIC (OSE) 00:00:00.316697 Installed Extension Packs: 00:00:00.316703 None installed! 00:00:00.317239 Console: Machine state changed to 'Starting' 00:00:00.317373 Qt version: 5.7.1 00:00:00.317382 X11 Window Manager code: 0 00:00:00.319488 GUI: UIMediumEnumerator: Medium-enumeration finished! 00:00:00.320181 X Server details: vendor: The XFree86 Project, Inc, release: 4030, protocol version: 11.0, display string: :0 00:00:00.320192 Using known keycode mapping for keycode to scan code conversion 00:00:00.321126 GUI: UIDesktopWidgetWatchdog::sltHandleHostScreenAvailableGeometryCalculated: Screen 0 work area is actually resized to: 0x0 x 1360x714 00:00:00.323320 SUP: Loaded VMMR0.r0 (/usr/local/lib/virtualbox/VMMR0.r0) at 0x - ModuleInit at and ModuleTerm at 00:00:00.323330 SUP: VMMR0EntryEx located at and VMMR0EntryFast at 00:00:00.325113 Guest OS type: 'Windows7_64' 00:00:00.329371 fHMForced=true - 64-bit guest 00:00:00.336703 File system of '/h/1/virtualbox/VirtualBox VMs/Erta/Snapshots' (snapshots) is ufs 00:00:00.336711 File system of '/h/1/virtualbox/VirtualBox VMs/Erta/C.vmdk' is ufs 00:00:00.340369 File system of '/h/1/virtualbox/VirtualBox VMs/Erta/D.vmdk' is ufs 00:00:00.342275 File system of '/h/1/virtualbox/VirtualBox VMs/Erta/H.vmdk' is ufs 00:00:00.344349 File system of '/h/1/virtualbox/VirtualBox VMs/Erta/V.vmdk' is ufs 00:00:00.352439 Shared clipboard service loaded 00:00:00.352448 Shared clipboard mode: Off 00:00:00.353451 Drag and drop service loaded 00:00:00.353454 Drag and drop mode: Off 00:00:00.354539 Guest Control service loaded 00:00:00.356695 * CFGM dump * 00:00:00.356698 [/] (level 0) 00:00:00.356701 CSAMEnabled= 0x0001 (1) 00:00:00.356705 CpuExecutionCap= 0x0064 (100) 00:00:00.356707 EnablePAE = 0x (0) 00:00:00.356709 HMEnabled = 0x0001 (1) 00:00:00.356711 MemBalloonSize = 0x (0) 00:00:00.356712 Name= "Erta" (cb=5) 00:00:00.356714 NumCPUs= 0x0001 (1) 00:00:00.356716 PATMEnabled= 0x0001 (1) 00:00:00.356717 PageFusionAllowed = 0x (0) 00:00:00.356718 RamHoleSize= 0x2000 (536 870 912, 512 MB) 00:00:00.356721 RamSize= 0xc000 (3 221 225 472, 3 072 MB, 3 GB) 00:00:00.356724 RawR0Enabled = 0x0001 (1) 00:00:00.356726 RawR3Enabled = 0x0001 (1) 00:00:00.356727 TimerMillies = 0x000a (10) 00:00:00.356729 UUID = "52 71 b0 18 b9 53 e6 4a ae 9b 48 d6 87 b7 17 f1" (cb=16) 00:00:00.356735 00:00:00.356736 [/CPUM/] (level 1) 00:00:00.356737 GuestCpuName = "host" (cb=5) 00:00:00.356739 PortableCpuIdLevel = 0x (0) 00:00:00.356740 00:00:00.356741 [/DBGC/] (level 1) 00:00:00.356742 GlobalInitScript = "/h/1/virtualbox/.config/VirtualBox/dbgc-init" (cb=45) 00:00:00.356743 HistoryFile= "/h/1/virtualbox/.config/VirtualBox/dbgc-history" (cb=48) 00:00:00.356745 LocalInitScript= "/h/1/virtualbox/VirtualBox VMs/Erta/dbgc-init" (cb=46) 00:00:00.356746 00:00:00.356747 [/DBGF/] (level 1) 00:00:00.356748 Path = "/h/1/virtualbox/VirtualBox VMs/Erta/debug/;/h/1/virtualbox/VirtualBox VMs/Erta/;/h/1/virtualbox/" (cb=97) 00:00:00.356749 00:00:00.356750 [/Devices/] (level 1) 00:00:00.356751 00:00:00.356752 [/Devices/8237A/] (level 2) 00:00:00.356753 00:00:00.356754 [/Devices/8237A/0/] (level 3) 00:00:00.356756 Trusted = 0x0001 (1) 00:00:00.356757 00:00:00.356758 [/Devices/GIMDev/] (level 2) 00:00:00.356759 00:00:00.356760 [/Devices/GIMDev/0/] (level 3) 00:00:00.356762 Trusted = 0x0001 (1) 00:00:00.356763 00:00:00.356763 [/Devices/VMMDev/] (level 2) 00:00:00.356765 00:00:00.356766 [/Devices/VMMDev/0/] (level 3) 00:00:00.3567
pkg and packages
After doing a general pkg upgrade on my server-of-all-work, I discovered after some research that the Big Grey Background I was left with was due to pkg having deleted, but not replaced, xfce4 desktop. Trying to install the desktop package, I discovered that it's bundled with at least 2 unrelated pieces of software: Thunar, and samba44. That bothered me, but I needed the desktop. pkg got totally confused during the install, first downloading 44 and THEN noticing the conflict with 46. So it downloaded 46, too(!), deleted the existing 46, installed 44, and then tried to re-install 46, failing with a complaint because it had just installed 44 and that created a conflict. But it gets better. Trying to reinstall the samba46 package, I discovered that I'd have to sacrifice the desktop that I just installed. Clearly, no good can come of packaging unrelated software together, so there needs to be a way to prevent that, or at least criticise those who do it. And pkg should (a) check for later versions *before* downloading older ones, (b) preferably not install old versions over newer without explicit permission, and (c) as a fallback should allow packages to be decomposed at install time such that installation is not a yes/no all-or-nothing choice. ___ 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 +-+ science/libint | 1-1-6 | v2.3.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: pkg and packages
On Wed, 03 May 2017 08:03:36 -0400 wrote > After doing a general pkg upgrade on my server-of-all-work, I > discovered after some research that the Big Grey Background I was > left with was due to pkg having deleted, but not replaced, xfce4 > desktop. > > Trying to install the desktop package, I discovered that it's > bundled with at least 2 unrelated pieces of software: Thunar, > and samba44. That bothered me, but I needed the desktop. > > pkg got totally confused during the install, first downloading 44 > and THEN noticing the conflict with 46. So it downloaded 46, > too(!), deleted the existing 46, installed 44, and then tried to > re-install 46, failing with a complaint because it had just > installed 44 and that created a conflict. > > But it gets better. Trying to reinstall the samba46 package, I > discovered that I'd have to sacrifice the desktop that I just > installed. > > Clearly, no good can come of packaging unrelated software > together, so there needs to be a way to prevent that, or at least > criticise those who do it. > > And pkg should (a) check for later versions *before* downloading > older ones, (b) preferably not install old versions over newer > without explicit permission, and (c) as a fallback should allow > packages to be decomposed at install time such that installation > is not a yes/no all-or-nothing choice. In pkg(8)'s humble defense; it simply *expedites* your request. It isn't the QA dept. for [port] Maintainers. Mind you; I *fully* appreciate your position. I'm simply trying to indicate *where*, or at *whom* to point fingers. :-) --Chris ___ 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: pkg and packages
On 2017/05/03 15:53, Chris H wrote: > On Wed, 03 May 2017 08:03:36 -0400 wrote > >> After doing a general pkg upgrade on my server-of-all-work, I >> discovered after some research that the Big Grey Background I was >> left with was due to pkg having deleted, but not replaced, xfce4 >> desktop. This is an annoying effect when it happens unexpectedly. However, I can't see how pkg(8) could behave otherwise. What happens is that if you say: pkg install foo pkg(8) works under the quite reasonable impression that you want foo installed. Now, if foo conflicts with another package you have installed, say 'bar', then pkg(8) will deinstall bar as an essential step towards getting foo installed. In general, this is what you would want to happen. 'Conflicts' here means either that the packages in question each install one or more files of the same name as one from the other package, or that one installs a shared library with an ABI version that matches the other package. The problem from your point of view is that as an intelligent being you see samba44 and samba46 as essentially different versions of the same thing. pkg(8) (all appearances to the contrary) is not at all intelligent, and can only treat the two different samba packages as completely distinct things. What would be great is if we could give a list of alternates as dependencies when creating packages, but unfortunately the packaging system does not have that capability. Yet. >> Trying to install the desktop package, I discovered that it's >> bundled with at least 2 unrelated pieces of software: Thunar, >> and samba44. That bothered me, but I needed the desktop. 'Bundling' isn't the right term -- Thunar and samba44 are /dependencies/ of the xfce4-desktop. That is: other packages that need to be installed before the package in question will work. Sorting out dependency trees like this is much of what pkg(8) exists for. >> pkg got totally confused during the install, first downloading 44 >> and THEN noticing the conflict with 46. So it downloaded 46, >> too(!), deleted the existing 46, installed 44, and then tried to >> re-install 46, failing with a complaint because it had just >> installed 44 and that created a conflict. >> >> But it gets better. Trying to reinstall the samba46 package, I >> discovered that I'd have to sacrifice the desktop that I just >> installed. >> >> Clearly, no good can come of packaging unrelated software >> together, so there needs to be a way to prevent that, or at least >> criticise those who do it. >> >> And pkg should (a) check for later versions *before* downloading >> older ones, (b) preferably not install old versions over newer >> without explicit permission, and (c) as a fallback should allow >> packages to be decomposed at install time such that installation >> is not a yes/no all-or-nothing choice. > > In pkg(8)'s humble defense; it simply *expedites* your request. > It isn't the QA dept. for [port] Maintainers. > Mind you; I *fully* appreciate your position. I'm simply trying to > indicate *where*, or at *whom* to point fingers. :-) Yes, indeed. pkg(8) does have a tendency to do exactly what you tell it, and sometimes that is not what you would intuitively expect. The thing that seems to trip most people up is thinking they can substitute some other package instead of the exact dependency listed in the package metadata. This is not an unreasonable request, especially when you know your alternate package does exactly the same thing as the one you want to replace. Unfortunately it just doesn't work right now, and it would take quite a lot of disruptive change in the ports tree and to pkg(8) itself to make that happen. Cheers, Matthew signature.asc Description: OpenPGP digital signature
Looking for a committer
Hello, can you commit zoneminder updates? https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217896 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=218292 ___ 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: MP3 licensing over - can we remove LAME restrictions?
Quoting Ben Woods (from Wed, 03 May 2017 07:18:18 +): "On April 23, 2017, Technicolor's mp3 licensing program for certain mp3 related patents and software of Technicolor and Fraunhofer IIS has been terminated." http://www.mp3licensing.com/ Putting my FreeBSD-hat aside and speaking as one of the project admins of LAME: What you list here are the Fraunhofer/Technicolor patents. There are at least 2 more parties involved. To what I was told the two other known patent portfolios are currently in the hands of Nokia and Sisvel. The later one being a very active party when it comes down to their intellectual property. I don't know anything about when patents from the other two portfolios expire, nor what those patents would be, nor if they are expired or not. My only knowledge is basically "there are more than those you quoted". It seems that the FreeBSD port for LAME could now have the restriction removed, allowing the packages to be available for users by default. My recommendation: not without legal advice (which IMO would be up for portmgr to seek for, together with the Foundation, if at all). In case we would go this way, I could ask my source of this information if he is willing to provide some more info as a seed for further investigation by someone else. Or if some Linux distro(s) are interested for a joined investigation (maybe the EFF is interested too)... Bye, Alexander. -- http://www.Leidinger.net alexan...@leidinger.net: PGP 0x8F31830F9F2772BF http://www.FreeBSD.orgnetch...@freebsd.org : PGP 0x8F31830F9F2772BF pgpbee4R5HRff.pgp Description: Digitale PGP-Signatur
Hash mismatch www/owncloud (10.0.0)
Helllo, I did a fresh install today and received a "code integrity" error in the admin page. It led to this: Technical information = The following list covers which files have failed the integrity check. Please read the previous linked documentation to learn more about the errors and how to fix them. Results === - user_external - INVALID_HASH - lib/smb.php Raw output == Array ( [user_external] => Array ( [INVALID_HASH] => Array ( [lib/smb.php] => Array ( [expected] => some_hash [current] => a_different_hash" ) ) ) ) Repeated the install and got the same error. I haven't done much testing, but the script seems to be "working". -- Jim Ohlstein ___ 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: Virtualbox 5.0.26 to 5.1.20/22 problem with upgrade.
Em Qua, 2017-05-03 às 12:39 +0200, Wojciech Puchar escreveu: > i'm asking you because it seems like i'm doing some simple and trivial > error. > > I run 8 VMs with windows 7 with virtualbox 5.0.26. All fine. > > After upgrading to 5.0.20 or 22 - none of them works. all crashes roughly > about the moment it switch from windows loading screen to normal screen. Mine was resolved when I BUILT virtualbox-ose WITHOUT the GL, that is: in the line 164 of the Makefile (/usr/ports/emulators/virtualbox-ose/Makefile) ghange USE_GL= gl do #USE_GL=gl and build virtualbox ose again, This soves me the problem I have by using virtualbox over vnc Hope can help you ___ 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: Hash mismatch www/owncloud (10.0.0)
On Wed, May 03, 2017 at 04:48:34PM -0400, Jim Ohlstein wrote: > > Helllo, Hi Jim, > I did a fresh install today and received a "code integrity" error in the > admin page. It led to this: > > Technical information > = > The following list covers which files have failed the integrity check. > Please read > the previous linked documentation to learn more about the errors and how > to fix > them. > > Results > === > - user_external > - INVALID_HASH > - lib/smb.php > > Raw output > == > Array > ( > [user_external] => Array > ( > [INVALID_HASH] => Array > ( > [lib/smb.php] => Array > ( > [expected] => some_hash > [current] => a_different_hash" > ) > > ) > > ) > > ) > > Repeated the install and got the same error. > > I haven't done much testing, but the script seems to be "working". Fixed in r440074, sorry for the breakage. > -- > Jim Ohlstein Kevin ___ 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"
