[aur-general] The license of flashplugin(-prerelease) requires a download?
There was some discussion in the flashplugin-prerelease's comment section[1] whether or not the PDF license of Flash Player (that is bigger than the tarball of the plugin itself) would be required to download along with the package. There was a suggestion to just use the post_install to link to the license (which the same guy said was redundant anyway because "We all know what we're installing, and how proprietary it is"). I could not care less for the license either but it's not that hard to just cut out the URL from the source=() section. So here we are. What do you guys think? Thanks for your time, Det [1] = http://aur.archlinux.org/packages.php?ID=32072
Re: [aur-general] The license of flashplugin(-prerelease) requires a download?
On 14.07.2011 20:03, Nimeton maili wrote: > There was some discussion in the flashplugin-prerelease's comment > section[1] whether or not the PDF license of Flash Player (that is > bigger than the tarball of the plugin itself) would be required to > download along with the package. > > There was a suggestion to just use the post_install to link to the > license (which the same guy said was redundant anyway because "We all > know what we're installing, and how proprietary it is"). > > I could not care less for the license either but it's not that hard to > just cut out the URL from the source=() section. > > So here we are. What do you guys think? > >Thanks for your time, >Det > > [1] = http://aur.archlinux.org/packages.php?ID=32072 Can't the PDF be extracted to plain text?
Re: [aur-general] The license of flashplugin(-prerelease) requires a download?
On Thu, Jul 14, 2011 at 1:06 PM, Sven-Hendrik Haase wrote: > On 14.07.2011 20:03, Nimeton maili wrote: > > There was some discussion in the flashplugin-prerelease's comment > > section[1] whether or not the PDF license of Flash Player (that is > > bigger than the tarball of the plugin itself) would be required to > > download along with the package. > > > > There was a suggestion to just use the post_install to link to the > > license (which the same guy said was redundant anyway because "We all > > know what we're installing, and how proprietary it is"). > > > > I could not care less for the license either but it's not that hard to > > just cut out the URL from the source=() section. > > > > So here we are. What do you guys think? > > > >Thanks for your time, > >Det > > > > [1] = http://aur.archlinux.org/packages.php?ID=32072 > Can't the PDF be extracted to plain text? > I like this solution if it is possible.
Re: [aur-general] The license of flashplugin(-prerelease) requires a download?
On Thu, Jul 14, 2011 at 3:06 PM, Sven-Hendrik Haase wrote: > Can't the PDF be extracted to plain text? > Or from the html page http://www.adobe.com/products/eulas/players/shockwave/ We need all the languages? -- “The journey is more important than the destination—that’s part of life, if you only live for getting to the end, you’re almost always disappointed.” Donald E. Knuth
Re: [aur-general] The license of flashplugin(-prerelease) requires a download?
On 14.07.2011 21:12, Kazuo Teramoto wrote: > On Thu, Jul 14, 2011 at 3:06 PM, Sven-Hendrik Haase > wrote: >> Can't the PDF be extracted to plain text? >> > Or from the html page http://www.adobe.com/products/eulas/players/shockwave/ > > We need all the languages? > All our licenses are English only as far as I am aware.
Re: [aur-general] The license of flashplugin(-prerelease) requires a download?
On 7/14/11, Thomas Dziedzic wrote: > On Thu, Jul 14, 2011 at 1:06 PM, Sven-Hendrik Haase wrote: > >> Can't the PDF be extracted to plain text? >> > > I like this solution if it is possible. > In that case the easiest way would probably be to just copy-paste the latest Flash Player EULA from here to a text file (as "LICENSE" or something alike) every time there is a major version bump: http://labs.adobe.com/technologies/eula/flashplayer11.html I'd guess just linking to this page is not sufficient (at least if you definitely want to avoid the cliché of poking the ice). This generally feels like a good idea and it's definitely better than downloading a stupid PDF. More ideas are still welcome, though.
[aur-general] large number of deprecated/duplicate flashplugin packages
All of these packages are either orphaned/out-of-date/duplicate or deprecated. Could someone delete these please ? http://aur.archlinux.org/packages.php?ID=47038 http://aur.archlinux.org/packages.php?ID=47308 http://aur.archlinux.org/packages.php?ID=49704 http://aur.archlinux.org/packages.php?ID=50704 http://aur.archlinux.org/packages.php?ID=44101 Also, adobe at one point had three seperate flash releases available, and had versioning/architecture issues that required three seperate AUR packages. Their last release consolidates all these releases, rendering two of these packages obsolete. Adobe also tends to use adjectives like prerelease/beta/preview randomly, causing further package naming issues. (eg, all -prerelease packages have now become -beta, when there used to be seperate -beta & -prerelease releases earlier). What's a good way to consolidate users of the three packages into the correct one ? -Anish -- As long as the music's loud enough, we won't hear the world falling apart.
[aur-general] PCSX2 Plugins folder - suggestion?
Hi all, I'm the maintainer of the package pcsx2-svn[1]. PCSX2 from now on will install files in a different folder than /opt/pcsx2 - I'm still going to adapt the PKGBUILD. Plugins, as I can see in Archlinux Packaging Standards [2], should go to /var/lib/pcsx2/PLUGINNAME.so... However, pcsx2 is a 32 bit package and only works in 64 bit because it uses lib32 packages. In my 64 bit system, I can see that the compilation of pcsx2 [gcc -m32, thanks to gcc-multilib] gives me ELF 32 bit plugins, which makes it a little bit weird to have it inside /var/lib/pcsx2 - which is a system's architecture folder. However, on 32 bit systems, there would be no problem putting plugins in /var/lib/pcsx2. Having that said, where should 32 and 64 bit compilations of PCSX2 put its plugins (talking about /varlib/pcsx2 and /var/lib32/pcsx2)? [1] http://aur.archlinux.org/packages.php?ID=21899 [2] https://wiki.archlinux.org/index.php/Arch_Packaging_Standards Thanks in advance, Rafael
Re: [aur-general] The license of flashplugin(-prerelease) requires a download?
On Thu, Jul 14, 2011 at 2:14 PM, Det wrote: > On 7/14/11, Thomas Dziedzic wrote: > > On Thu, Jul 14, 2011 at 1:06 PM, Sven-Hendrik Haase >wrote: > > > >> Can't the PDF be extracted to plain text? > >> > > > > I like this solution if it is possible. > > > > In that case the easiest way would probably be to just copy-paste the > latest Flash Player EULA from here to a text file (as "LICENSE" or > something alike) every time there is a major version bump: > http://labs.adobe.com/technologies/eula/flashplayer11.html > > I'd guess just linking to this page is not sufficient (at least if you > definitely want to avoid the cliché of poking the ice). > > This generally feels like a good idea and it's definitely better than > downloading a stupid PDF. More ideas are still welcome, though. > I think ubuntu just ships with a flashplugin installer, and it fetches the plugin at install time. from http://packages.ubuntu.com/natty/flashplugin-installer "The distribution license of the Adobe Flash Player plugin is available at www.adobe.com. Installing this Ubuntu package implies that you have accepted the terms of that license." I think they can get away with not shipping a license file because they don't actually ship the binary. If that's the case, maybe we can get away with just stating that in the postinstall message, as long as the package remains in the aur.
Re: [aur-general] large number of deprecated/duplicate flashplugin packages
On 14 July 2011 22:34, Anish Bhatt wrote: > All of these packages are either orphaned/out-of-date/duplicate or > deprecated. Could someone delete these please ? > > http://aur.archlinux.org/packages.php?ID=47038 > http://aur.archlinux.org/packages.php?ID=47308 > http://aur.archlinux.org/packages.php?ID=49704 > http://aur.archlinux.org/packages.php?ID=50704 > http://aur.archlinux.org/packages.php?ID=44101 All removed. > Also, adobe at one point had three seperate flash releases available, and > had versioning/architecture issues that required three seperate AUR > packages. Their last release consolidates all these releases, rendering two > of these packages obsolete. Adobe also tends to use adjectives like > prerelease/beta/preview randomly, causing further package naming issues. > (eg, all -prerelease packages have now become -beta, when there used to be > seperate -beta & -prerelease releases earlier). What's a good way to > consolidate users of the three packages into the correct one ? Post a comment on the packages that will be deleted, suggesting to switch to the flashplugin-beta package. After a couple of weeks, we can go ahead and delete the -prerelease packages.
Re: [aur-general] large number of deprecated/duplicate flashplugin packages
Am Fri, 15 Jul 2011 02:08:11 +0300 schrieb Evangelos Foutras : > On 14 July 2011 22:34, Anish Bhatt wrote: > > All of these packages are either orphaned/out-of-date/duplicate or > > deprecated. Could someone delete these please ? > > > > http://aur.archlinux.org/packages.php?ID=47038 > > http://aur.archlinux.org/packages.php?ID=47308 > > http://aur.archlinux.org/packages.php?ID=49704 > > http://aur.archlinux.org/packages.php?ID=50704 > > http://aur.archlinux.org/packages.php?ID=44101 > > All removed. What's about these flashplugin packages? flashplugin9 (http://aur.archlinux.org/packages.php?ID=21045) Totally outdated and most likely full of security holes. lib32-flashplugin (http://aur.archlinux.org/packages.php?ID=15406) Seems to be identical with flashplugin from [multilib] and misses some files like the .desktop file. lib32-flashplugin10.1 (http://aur.archlinux.org/packages.php?ID=49982) Seems to be the same as lib32-flashplugin but outdated. Heiko
Re: [aur-general] large number of deprecated/duplicate flashplugin packages
On 15 July 2011 02:22, Heiko Baums wrote: > What's about these flashplugin packages? > > flashplugin9 (http://aur.archlinux.org/packages.php?ID=21045) > Totally outdated and most likely full of security holes. Quite outdated indeed; removed. > lib32-flashplugin (http://aur.archlinux.org/packages.php?ID=15406) > Seems to be identical with flashplugin from [multilib] and misses some > files like the .desktop file. That package doesn't use nspluginwrapper like the one in [multilib]. > lib32-flashplugin10.1 (http://aur.archlinux.org/packages.php?ID=49982) > Seems to be the same as lib32-flashplugin but outdated. They're different versions. Maybe it should be deleted, but I'll leave it as is for the moment.
[aur-general] Orphan request
Please orphan zpaq [1]. I contacted tuxspirit by email and he agreed to transfer it to me, but he forgot to orphan the package and he doesn't seem to check his emails often (more than a week with no replies). [1] https://aur.archlinux.org/packages.php?ID=29726
Re: [aur-general] PCSX2 Plugins folder - suggestion?
On Thu, Jul 14, 2011 at 4:41 PM, rafael ff1 wrote: > Hi all, > > I'm the maintainer of the package pcsx2-svn[1]. PCSX2 from now on will > install files in a different folder than /opt/pcsx2 - I'm still going > to adapt the PKGBUILD. Plugins, as I can see in Archlinux Packaging > Standards [2], should go to /var/lib/pcsx2/PLUGINNAME.so... However, > pcsx2 is a 32 bit package and only works in 64 bit because it uses > lib32 packages. > > In my 64 bit system, I can see that the compilation of pcsx2 [gcc > -m32, thanks to gcc-multilib] gives me ELF 32 bit plugins, which makes > it a little bit weird to have it inside /var/lib/pcsx2 - which is a > system's architecture folder. However, on 32 bit systems, there would > be no problem putting plugins in /var/lib/pcsx2. > > Having that said, where should 32 and 64 bit compilations of PCSX2 put > its plugins (talking about /varlib/pcsx2 and /var/lib32/pcsx2)? > > [1] http://aur.archlinux.org/packages.php?ID=21899 > [2] https://wiki.archlinux.org/index.php/Arch_Packaging_Standards > > Thanks in advance, > > Rafael > I think that you mean /usr/lib/pcsx2 instead of /var/lib/pcsx2. Since plugins are just specialized dynamic libraries my gut feeling is they belong under /usr/lib. On the Arch Packaging Standards page it also says to use /usr/lib/pcsx2. Using two different folders depending on the host architecture is overly complicated. The advantage of a "lib32" directory name is to separate lib32 dynamic libs from 64-bit dynamic libs right? There's no need to separate plugins if there is no chance of them getting accidentally used. They cannot be passively used but must be actively sought out in the predefined location. I don't use multilib so I may be wrong. -- -Justin
Re: [aur-general] Orphan request
On 07/15/2011 02:11 AM, Marco Schulze wrote: Please orphan zpaq [1]. I contacted tuxspirit by email and he agreed to transfer it to me, but he forgot to orphan the package and he doesn't seem to check his emails often (more than a week with no replies). [1] https://aur.archlinux.org/packages.php?ID=29726 Done.
Re: [aur-general] PCSX2 Plugins folder - suggestion?
2011/7/14 Justin Davis : > I think that you mean /usr/lib/pcsx2 instead of /var/lib/pcsx2. (...) Indeed, thanks for correcting me. > > Using two different folders depending on the host architecture is > overly complicated. The advantage of a "lib32" directory name is to > separate lib32 dynamic libs from 64-bit dynamic libs right? There's no > need to separate plugins if there is no chance of them getting > accidentally used. They cannot be passively used but must be actively > sought out in the predefined location. I don't use multilib so I may > be wrong. > It happens that if you are in 64-bit Arch, you will build for PCSX2 32-bit plugins. If you are in 32-bit Arch, you will also build 32-bit plugins. The difference is that [multilib] system (only for 64-bit system) has 32-bit lib files at /usr/lib32 - separated from 64-bit lib files. If the plugins are 32-bit, it's logical to put them in /usr/lib/pcsx2 in 32-bit system. But in 64-bit system, I'm not sure if they whether I should put them in /usr/lib or /usrlib32/ (inside "pcsx2" folder, of course). Installing this package's plugin folder differently according to architecture seems weird. - I could be wrong. > -- > -Justin > Rafael
