Re: [arch-general] Add MIT Licence to /usr/share/licences/common
On Sun, Nov 04, 2018 at 01:21:28AM +0100, mpan wrote: > > >>> It states MIT/BSD are special cases, just out of curiousity, what makes > >>> them special that they cannot be added? > >> Because there is no MIT or 1/2/3-clause BSD license. There are > >> hundreds of independent, barely related licenses that are quite similar > >> and, therefore, are considered together as a class of MIT licens*es* > >> (note the plural), 1/2/3-clause BSD licens*es* etc. Despite many of them > >> may be very similar and, in fact, usually they share huge portion of the > >> text, they are formally different agreements. > >> > >> In the above explanation I do not support any of the sides. Whether > >> classes that share 100% of important content and 99% of formatting > >> content, should be considered similar enough to have a shared entry in > >> Arch’s licenses directory, is a separate decision. I am just explaining. > > > > It has nothing to do with any of that. It's simply that those licenses have > > project-specific copyright information added to them and cannot be generic. > Approximately the same as what I’ve just said, but less > verbose/precise. :) > You didn't mention the word copyright once, you just managed to confuse people, myself included. Orwell said "never use a long word where a short one will do", and this question has already been answered multiple times. Can we close the thread now? - L signature.asc Description: PGP signature
Re: [arch-general] Add MIT Licence to /usr/share/licences/common
>>> It states MIT/BSD are special cases, just out of curiousity, what makes >>> them special that they cannot be added? >> Because there is no MIT or 1/2/3-clause BSD license. There are >> hundreds of independent, barely related licenses that are quite similar >> and, therefore, are considered together as a class of MIT licens*es* >> (note the plural), 1/2/3-clause BSD licens*es* etc. Despite many of them >> may be very similar and, in fact, usually they share huge portion of the >> text, they are formally different agreements. >> >> In the above explanation I do not support any of the sides. Whether >> classes that share 100% of important content and 99% of formatting >> content, should be considered similar enough to have a shared entry in >> Arch’s licenses directory, is a separate decision. I am just explaining. > > It has nothing to do with any of that. It's simply that those licenses have > project-specific copyright information added to them and cannot be generic. Approximately the same as what I’ve just said, but less verbose/precise. :) signature.asc Description: OpenPGP digital signature
Re: [arch-general] Add MIT Licence to /usr/share/licences/common
On Sun, 4 Nov 2018 00:24:14 +0100 mpan wrote: > > It states MIT/BSD are special cases, just out of curiousity, what makes > > them special that they cannot be added? > Because there is no MIT or 1/2/3-clause BSD license. There are > hundreds of independent, barely related licenses that are quite similar > and, therefore, are considered together as a class of MIT licens*es* > (note the plural), 1/2/3-clause BSD licens*es* etc. Despite many of them > may be very similar and, in fact, usually they share huge portion of the > text, they are formally different agreements. > > In the above explanation I do not support any of the sides. Whether > classes that share 100% of important content and 99% of formatting > content, should be considered similar enough to have a shared entry in > Arch’s licenses directory, is a separate decision. I am just explaining. It has nothing to do with any of that. It's simply that those licenses have project-specific copyright information added to them and cannot be generic.
Re: [arch-general] Add MIT Licence to /usr/share/licences/common
> It states MIT/BSD are special cases, just out of curiousity, what makes them > special that they cannot be added? Because there is no MIT or 1/2/3-clause BSD license. There are hundreds of independent, barely related licenses that are quite similar and, therefore, are considered together as a class of MIT licens*es* (note the plural), 1/2/3-clause BSD licens*es* etc. Despite many of them may be very similar and, in fact, usually they share huge portion of the text, they are formally different agreements. In the above explanation I do not support any of the sides. Whether classes that share 100% of important content and 99% of formatting content, should be considered similar enough to have a shared entry in Arch’s licenses directory, is a separate decision. I am just explaining. signature.asc Description: OpenPGP digital signature
Re: [arch-general] Hardware portal
Saturday, November 3, 2018 6:47 PM, Andrey Ponomarenko via arch-general wrote: > Hi, > > Good news for everyone interested in Linux-compatibility and reliability of > hardware! > > The Linux-Hardware.org database has been divided into a set of databases, one > per each Linux distro. You can now select your favorite distro on the front > page: Do you consider people wishing to submit reviews or collect reports from the interwob about folks not happy with a particular device? I know your fully automated approach seems like an easy kill, but really, I could upload my laptop to the database, but then it would nowhere tell that the particular laptop I'm using is known to be a piece of garbage. Wine has an approach that would allow me to make the case clear, but this may be orthogonal to the kind of thing you're doing... Or maybe I'm misunderstanding the purpose of your database: is it supposed to be the central point around which people should make decisions on what hardware they should buy or avoid? cheers! mar77i Sent with ProtonMail Secure Email.
Re: [arch-general] Hardware portal
On Sat, 03 Nov 2018 20:47:17 +0300 Andrey Ponomarenko via arch-general wrote: > Hi, > > Good news for everyone interested in Linux-compatibility and > reliability of hardware! > > The Linux-Hardware.org database has been divided into a set of > databases, one per each Linux distro. You can now select your > favorite distro on the front page: > > https://linux-hardware.org/?d=Arch > > In this mode you'll not see data collected from other Linux distros. > > One can submit computer hardware info to the database automatically > by AppImage, Snap, Flatpak, Docker or native package: > https://github.com/linuxhw/hw-probe#install > > Enjoy! Far Far far superior as a full searchable list this is to put it very mildly pants .. Pete .
Re: [arch-general] Add MIT Licence to /usr/share/licences/common
Saturday, November 3, 2018 7:53 PM, John Ramsden via arch-general dixit: > It states MIT/BSD are special cases, just out of curiousity, what makes them > special that they cannot be added? Look at them: https://opensource.org/licenses/BSD-2-Clause https://opensource.org/licenses/MIT For one, they're copyright notices. And they're individual for each project. The license states that the above copyright notice must be included in the license which is distributed with the project. So they can't be generalized. cheers! mar77i Sent with ProtonMail Secure Email.
Re: [arch-general] Add MIT Licence to /usr/share/licences/common
On Sat, Nov 03, 2018 at 11:53:45AM -0700, John Ramsden via arch-general wrote: > It states MIT/BSD are special cases, just out of curiousity, what makes them > special that they cannot be added? > I believe the reasoning for that is they include program-specific copyright information, so you can't just use a reference copy of the license in this case. - Luke English > -- > John Ramsden > > On Sat, Nov 3, 2018, at 1:22 AM, Bruno Pagani via arch-general wrote: > > Hi, > > > > Le 03/11/2018 à 08:46, Stephen Gregoratto via arch-general a écrit : > > > I'm in the process of adding a new package to the AUR, when I noticed > > > that the MIT Licence - which this program is licensed under - is not > > > available under /usr/share/licenses/common. Seeing that it's a fairly > > > popular license that is copied by a number of packages (many of them > > > Rust based: find /usr/share/licenses -name "*MIT*"), I think it would be > > > beneficial if there could be a copy of the MIT license in the licenses > > > package. > > > > > > I've attached a diff of my edits to licenses trunk. Note that I copied > > > the licence file from rust/LICENCE-MIT and ran updpkgsums. Also, it > > > seems the PHP-3.0 licence has changed, and its checksum has updated as > > > well. > > > > Please read https://wiki.archlinux.org/index.php/PKGBUILD#license > > > > Especially the first bullet point. > > > > Regards, > > Bruno > > > > > > Email had 1 attachment: > > + signature.asc > > 1k (application/pgp-signature) signature.asc Description: PGP signature
Re: [arch-general] Add MIT Licence to /usr/share/licences/common
It states MIT/BSD are special cases, just out of curiousity, what makes them special that they cannot be added? -- John Ramsden On Sat, Nov 3, 2018, at 1:22 AM, Bruno Pagani via arch-general wrote: > Hi, > > Le 03/11/2018 à 08:46, Stephen Gregoratto via arch-general a écrit : > > I'm in the process of adding a new package to the AUR, when I noticed > > that the MIT Licence - which this program is licensed under - is not > > available under /usr/share/licenses/common. Seeing that it's a fairly > > popular license that is copied by a number of packages (many of them > > Rust based: find /usr/share/licenses -name "*MIT*"), I think it would be > > beneficial if there could be a copy of the MIT license in the licenses > > package. > > > > I've attached a diff of my edits to licenses trunk. Note that I copied > > the licence file from rust/LICENCE-MIT and ran updpkgsums. Also, it > > seems the PHP-3.0 licence has changed, and its checksum has updated as > > well. > > Please read https://wiki.archlinux.org/index.php/PKGBUILD#license > > Especially the first bullet point. > > Regards, > Bruno > > > Email had 1 attachment: > + signature.asc > 1k (application/pgp-signature)
Re: [arch-general] Problems Building Nuvolaplayer-git
On Saturday, November 3, 2018 10:57:53 AM MST, Hunter Jozwiak via arch-general wrote: Hello, [snip] Does anyone who has had experience with Nuvola know of the solution to this problem? Is there a package missing that didn't get added to the dependencies? The issue is an old version of waf that's not compatible with Python 3.7, and not likely to get updated anytime soon, alas. You could try manually updating what Nuvola is using to waf 2.0.7 or later... ...or, if you're using Nuvola for Google or YouTube Music, may I suggest you try Google Play Music Desktop Player[1] instead? [1]: https://aur.archlinux.org/packages/gpmdp/ ~Celti
[arch-general] Problems Building Nuvolaplayer-git
Hello,
I am having the following problem in building the nuvolaplayer-git package.
:: Checking for conflicts... :: Checking for inner conflicts... [Aur: 1]
nuvolaplayer-git-r1020.78b0333-1 1 nuvolaplayer-git (Build Files Exist) ==>
Packages to cleanBuild? ==> [N]one [A]ll [Ab]ort [I]nstalled [No]tInstalled
or (1 2 3, 1-3, ^4) ==> :: PKGBUILD up to date, Skipping (1/1):
nuvolaplayer-git 1 nuvolaplayer-git (Build Files Exist) ==> [N]one [A]ll
[Ab]ort [I]nstalled [No]tInstalled or (1 2 3, 1-3, ^4) ==> Diffs to show?
==> :: Parsing SRCINFO (1/1): nuvolaplayer-git ==> The following packages
are not compatible with your architecture: nuvolaplayer-git ==> Try to
build them anyway? [Y/n] ==> Making package: nuvolaplayer-git
r1020.78b0333-1 (Sat 03 Nov 2018 01:45:41 PM EDT) ==> Retrieving sources...
-> Updating nuvolaplayer-git git repo... Fetching origin ==> Validating
source files with md5sums... nuvolaplayer-git ... Skipped ==> Cleaning
up... ==> Making package: nuvolaplayer-git r1020.78b0333-1 (Sat 03 Nov 2018
01:45:43 PM EDT) ==> Checking runtime dependencies... ==> Checking
buildtime dependencies... ==> Retrieving sources... -> Updating
nuvolaplayer-git git repo... Fetching origin ==> Validating source files
with md5sums... nuvolaplayer-git ... Skipped ==> Removing existing $srcdir/
directory... ==> Extracting sources... -> Creating working copy of
nuvolaplayer-git git repo... Cloning into 'nuvolaplayer-git'... done. ==>
Starting pkgver()... ==> Updated version: nuvolaplayer-git r1755.fbb4b9f-1
==> Sources are ready. ==> Making package: nuvolaplayer-git r1755.fbb4b9f-1
(Sat 03 Nov 2018 01:45:47 PM EDT) ==> Checking runtime dependencies... ==>
Checking buildtime dependencies... ==> WARNING: Using existing $srcdir/
tree ==> Starting pkgver()... ==> Starting build()... Traceback (most
recent call last): File
"/home/sektor/.cache/yay/nuvolaplayer-git/src/nuvolaplayer-git/.waf3-2.0.6-593191f496fe8c66231dfd5df26167ae/waflib/Node.py",
line 342, in ant_iter raise StopIteration StopIteration The above exception
was the direct cause of the following exception: Traceback (most recent
call last): File
"/home/sektor/.cache/yay/nuvolaplayer-git/src/nuvolaplayer-git/.waf3-2.0.6-593191f496fe8c66231dfd5df26167ae/waflib/Scripting.py",
line 118, in waf_entry_point run_commands() File
"/home/sektor/.cache/yay/nuvolaplayer-git/src/nuvolaplayer-git/.waf3-2.0.6-593191f496fe8c66231dfd5df26167ae/waflib/Scripting.py",
line 174, in run_commands parse_options() File
"/home/sektor/.cache/yay/nuvolaplayer-git/src/nuvolaplayer-git/.waf3-2.0.6-593191f496fe8c66231dfd5df26167ae/waflib/Scripting.py",
line 157, in parse_options ctx.execute() File
"/home/sektor/.cache/yay/nuvolaplayer-git/src/nuvolaplayer-git/.waf3-2.0.6-593191f496fe8c66231dfd5df26167ae/waflib/Options.py",
line 198, in execute super(OptionsContext,self).execute() File
"/home/sektor/.cache/yay/nuvolaplayer-git/src/nuvolaplayer-git/.waf3-2.0.6-593191f496fe8c66231dfd5df26167ae/waflib/Context.py",
line 84, in execute self.recurse([os.path.dirname(g_module.root_path)])
File
"/home/sektor/.cache/yay/nuvolaplayer-git/src/nuvolaplayer-git/.waf3-2.0.6-593191f496fe8c66231dfd5df26167ae/waflib/Context.py",
line 125, in recurse user_function(self) File
"/home/sektor/.cache/yay/nuvolaplayer-git/src/nuvolaplayer-git/wscript",
line 292, in options ctx.load('compiler_c vala') File
"/home/sektor/.cache/yay/nuvolaplayer-git/src/nuvolaplayer-git/.waf3-2.0.6-593191f496fe8c66231dfd5df26167ae/waflib/Context.py",
line 82, in load fun(self) File
"/home/sektor/.cache/yay/nuvolaplayer-git/src/nuvolaplayer-git/.waf3-2.0.6-593191f496fe8c66231dfd5df26167ae/waflib/Tools/compiler_c.py",
line 40, in options
opt.load_special_tools('c_*.py',ban=['c_dumbpreproc.py']) File
"/home/sektor/.cache/yay/nuvolaplayer-git/src/nuvolaplayer-git/.waf3-2.0.6-593191f496fe8c66231dfd5df26167ae/waflib/Context.py",
line 326, in load_special_tools
lst=self.root.find_node(waf_dir).find_node('waflib/extras').ant_glob(var)
File
"/home/sektor/.cache/yay/nuvolaplayer-git/src/nuvolaplayer-git/.waf3-2.0.6-593191f496fe8c66231dfd5df26167ae/waflib/Node.py",
line 358, in ant_glob return list(it) RuntimeError: generator raised
StopIteration ==> ERROR: A failure occurred in build(). Aborting... Error
making: nuvolaplayer-git
Does anyone who has had experience with Nuvola know of the solution to this
problem? Is there a package missing that didn't get added to the
dependencies?
Thanks,
Hunter
[arch-general] Hardware portal
Hi, Good news for everyone interested in Linux-compatibility and reliability of hardware! The Linux-Hardware.org database has been divided into a set of databases, one per each Linux distro. You can now select your favorite distro on the front page: https://linux-hardware.org/?d=Arch In this mode you'll not see data collected from other Linux distros. One can submit computer hardware info to the database automatically by AppImage, Snap, Flatpak, Docker or native package: https://github.com/linuxhw/hw-probe#install Enjoy!
Re: [arch-general] Static Lib Build for SDL2
Hmm, sorry for the noise. You can safely ignore the mail. The problem was caused by incompatible configuration in other operating systems, not ArchLinux. -- Cheers Jayesh Badwaik https://jayeshbadwaik.github.io signature.asc Description: This is a digitally signed message part.
Re: [arch-general] Static Lib Build for SDL2
Fixed the link: https://git.archlinux.org/svntogit/packages.git/tree/trunk/PKGBUILD?h=packages/sdl2#n50 -- Jayesh Badwaik https://jayeshbadwaik.github.io signature.asc Description: This is a digitally signed message part.
[arch-general] Static Lib Build for SDL2
Hi, As I currently notice here (line 32) https://git.archlinux.org/svntogit/packages.git/tree/trunk/PKGBUILD? h=packages/sdl2#n31 The SDL2 library is not build with a static component. This is useful for a lot of development and hence, it would be nice if it is build with static component. Also, it would be also good if the line 50 of the package was not done, since that causes problem with using CMake files portably across other systems. If instead such a thing is needed, I would suggest that a symlink `libSDL2.a` be created to point to `SDL2main.a`. Cheers -- Jayesh Badwaik https://jayeshbadwaik.github.io signature.asc Description: This is a digitally signed message part.
Re: [arch-general] Problem install shrew vpn client
El sáb., 3 nov. 2018 0:34, Joan Figueras via arch-general < arch-general@archlinux.org> escribió: > On 26/9/18 10:47, Maykel Franco via arch-general wrote: > > Hi, I received this error when compile the program shrew vpn client: > > > > yaourt -S shrew-vpn-client > > > > > /tmp/yaourt-tmp-maykel/aur-shrew-vpn-client/src/ike/source/libike/manager.file.cpp: > > In member function 'bool _CONFIG_MANAGER::file_pcf_load(CONFIG&, const > > char*, bool&)': > > > /tmp/yaourt-tmp-maykel/aur-shrew-vpn-client/src/ike/source/libike/manager.file.cpp:682:19: > > error: aggregate 'EVP_CIPHER_CTX ctx_cipher' has incomplete type and > > cannot be defined > > EVP_CIPHER_CTX ctx_cipher; > > ^~ > > make[2]: *** [source/libike/CMakeFiles/ss_ike.dir/build.make:102: > > source/libike/CMakeFiles/ss_ike.dir/manager.file.o] Error 1 > > make[2]: *** Waiting for unfinished jobs > > [ 24%] Linking CXX shared library libss_ip.so > > [ 25%] Linking CXX shared library libss_pfk.so > > [ 25%] Built target ss_ip > > [ 25%] Built target ss_pfk > > make[1]: *** [CMakeFiles/Makefile2:244: > > source/libike/CMakeFiles/ss_ike.dir/all] Error 2 > > make: *** [Makefile:130: all] Error 2 > > ==> ERROR: A failure occurred in build(). > > Aborting... > > ==> ERROR: Makepkg was unable to build shrew-vpn-client. > > > > > > > > Someone happened to him the same? > > > > Thanks in advanced. > > I've just posted a patch to build shrew in AUR: > > https://aur.archlinux.org/packages/shrew-vpn-client/#news > > > Cheers > > Joan > Thanks everybody. I use the ike client un the command línea and it works. >
Re: [arch-general] Add MIT Licence to /usr/share/licences/common
Hi, Le 03/11/2018 à 08:46, Stephen Gregoratto via arch-general a écrit : > I'm in the process of adding a new package to the AUR, when I noticed > that the MIT Licence - which this program is licensed under - is not > available under /usr/share/licenses/common. Seeing that it's a fairly > popular license that is copied by a number of packages (many of them > Rust based: find /usr/share/licenses -name "*MIT*"), I think it would be > beneficial if there could be a copy of the MIT license in the licenses > package. > > I've attached a diff of my edits to licenses trunk. Note that I copied > the licence file from rust/LICENCE-MIT and ran updpkgsums. Also, it > seems the PHP-3.0 licence has changed, and its checksum has updated as > well. Please read https://wiki.archlinux.org/index.php/PKGBUILD#license Especially the first bullet point. Regards, Bruno signature.asc Description: OpenPGP digital signature
[arch-general] Add MIT Licence to /usr/share/licences/common
I'm in the process of adding a new package to the AUR, when I noticed
that the MIT Licence - which this program is licensed under - is not
available under /usr/share/licenses/common. Seeing that it's a fairly
popular license that is copied by a number of packages (many of them
Rust based: find /usr/share/licenses -name "*MIT*"), I think it would be
beneficial if there could be a copy of the MIT license in the licenses
package.
I've attached a diff of my edits to licenses trunk. Note that I copied
the licence file from rust/LICENCE-MIT and ran updpkgsums. Also, it
seems the PHP-3.0 licence has changed, and its checksum has updated as
well.
--
Stephen Gregoratto
Index: PKGBUILD
===
--- PKGBUILD(revision 337753)
+++ PKGBUILD(working copy)
@@ -2,7 +2,7 @@
# Maintainer: Dan McGee
pkgname=licenses
-pkgver=20171006
+pkgver=20181103
pkgrel=1
pkgdesc='Standard licenses distribution package'
arch=('any')
@@ -38,7 +38,8 @@
ZopePublicLicense.txt
mpl-1.1.txt::https://www.mozilla.org/media/MPL/1.1/index.txt
mpl-2.0.txt::https://www.mozilla.org/media/MPL/2.0/index.txt
-boost-1.0.txt::http://www.boost.org/LICENSE_1_0.txt)
+boost-1.0.txt::http://www.boost.org/LICENSE_1_0.txt
+mit.txt)
md5sums=('3b83ef96387f14655fc854ddc3c6bd57'
'ffb24d1bbf8b83d373f0b8edc3feb0c6'
'682a5e3b03510ba46c4f566478c871bc'
@@ -59,7 +60,7 @@
'9f4337828d782bdea41f03dd2ad1b808'
'd09c120ca7db95ef2aeecec0cb08293b'
'b4a94da2a1f918b217ef5156634fc9e0'
- 'a45bb1bbeed9e26b26c5763df1d3913d'
+ '00b4bd92b48eaed71b4e4e7b7314c3b6'
'8a960b08d972f43f91ae84a6f00dcbfb'
'f083e41c43db25e18f36c91e57750b64'
'a055911c32fb4ed6e96c453ceaeba857'
@@ -67,7 +68,8 @@
'dc8502850eab9e1ff330a12d7ca18a19'
'0c5913925d40b124fb52ce84c5deb3f3'
'815ca599c9df247a0c7f619bab123dad'
- 'e4224ccaecb14d942c71d31bef20d78c')
+ 'e4224ccaecb14d942c71d31bef20d78c'
+ 'b377b220f43d747efdec40d69fcaa69d')
package() {
cd "$pkgdir"
@@ -147,6 +149,9 @@
mkdir Boost
cp "$srcdir"/boost-1.0.txt Boost/license.txt
+
+ mkdir MIT
+ cp "$srcdir"/mit.txt MIT/licence.txt
}
# vim: ts=2 sw=2 et:
Index: mit.txt
===
--- mit.txt (nonexistent)
+++ mit.txt (working copy)
@@ -0,0 +1,23 @@
+Permission is hereby granted, free of charge, to any
+person obtaining a copy of this software and associated
+documentation files (the "Software"), to deal in the
+Software without restriction, including without
+limitation the rights to use, copy, modify, merge,
+publish, distribute, sublicense, and/or sell copies of
+the Software, and to permit persons to whom the Software
+is furnished to do so, subject to the following
+conditions:
+
+The above copyright notice and this permission notice
+shall be included in all copies or substantial portions
+of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF
+ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED
+TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A
+PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT
+SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY
+CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION
+OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR
+IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+DEALINGS IN THE SOFTWARE.
