- Aur-general - lists.archlinux.org

[aur-general] Compiz package naming
by Rob McCathie 09 Jan '15

09 Jan '15

Hello AUR general & Compiz package maintainers. There was some discussion about Compiz packages a little while ago, i don't think that much came of it. I'd like to re-open the discussion. My opinions/suggestions: Calling the 0.8 series "compiz" and the 0.9 series "compiz-devel" is no longer correct, it hasn't been for quite some time. All information on this page: http://www.compiz.org/ is completely wrong and out of date, like 5 years out of date, and should not be used as a reference for anything. Tracking of the state of Compiz should be done from here: https://launchpad.net/compiz Development of the 0.8 series is as close to being dead as it could be. Unless you count 2 tiny commits 5 months ago, nothing has been done in 16 months, and even that 16 month old commit was a minor change just to get it working with KDE 4.10, with the commit prior to that being an additional 5 months back. http://cgit.compiz.org/compiz/core/log/?h=compiz-0.8 My suggestion is pretty simple, "compiz" becomes the 0.9 series, the 0.8 series becomes "compiz-legacy". Any 0.9 series packages that have "core" in their name should have it removed, since the concept of Compiz being split up has been dropped since the 0.9 series. The 0.9 series doesn't have a "core" component, it's just "compiz". Some examples: martadinata666's "compiz-core" package would become "compiz-legacy-core" dev_rs0's "compiz-core-devel" package would become simply "compiz" Chazza's "compiz-core-bzr" package would become "compiz-bzr" flexiondotorg's "compiz-core-mate" package would become "compiz-legacy-core-mate" My "compiz-gtk-standalone" package would become "compiz-legacy-gtk-standalone" All the "compiz-fusion-plugins-*" packages would become "compiz-legacy-fusion-plugins-*" ...and so on. What are everyone's thoughts? -- Regards, Rob McCathie

9 22

[aur-general] Signoff report for [community-testing]
by Arch Website Notification 09 Jan '15

09 Jan '15

=== Signoff report for [community-testing] === https://www.archlinux.org/packages/signoffs/ There are currently: * 0 new packages in last 24 hours * 0 known bad packages * 0 packages not accepting signoffs * 0 fully signed off packages * 21 packages missing signoffs * 15 packages older than 14 days (Note: the word 'package' as used here refers to packages as grouped by pkgbase, architecture, and repository; e.g., one PKGBUILD produces one package per architecture, even if it is a split package.) == Incomplete signoffs for [community] (19 total) == * eric-6.0.0-1 (any) 1/2 signoffs * eric-i18n-6.0.0-1 (any) 1/2 signoffs * freevo-1.9.0-14 (any) 0/2 signoffs * acpi_call-1.1.0-17 (i686) 0/1 signoffs * bbswitch-0.8-21 (i686) 0/1 signoffs * python-h5py-2.4.0-1 (i686) 0/1 signoffs * r8168-8.039.00-6 (i686) 0/1 signoffs * rt3562sta-2.4.1.1_r1-15 (i686) 0/1 signoffs * tp_smapi-0.41-58 (i686) 0/1 signoffs * vhba-module-20140928-1 (i686) 0/1 signoffs * virtualbox-modules-4.3.20-4 (i686) 0/1 signoffs * acpi_call-1.1.0-17 (x86_64) 0/2 signoffs * bbswitch-0.8-21 (x86_64) 0/2 signoffs * python-h5py-2.4.0-1 (x86_64) 0/2 signoffs * r8168-8.039.00-6 (x86_64) 0/2 signoffs * rt3562sta-2.4.1.1_r1-15 (x86_64) 0/2 signoffs * tp_smapi-0.41-58 (x86_64) 0/2 signoffs * vhba-module-20140928-1 (x86_64) 0/2 signoffs * virtualbox-modules-4.3.20-4 (x86_64) 0/2 signoffs == Incomplete signoffs for [unknown] (2 total) == * qscintilla-qt5-2.8.4-2 (i686) 0/1 signoffs * qscintilla-qt5-2.8.4-2 (x86_64) 1/2 signoffs == All packages in [community-testing] for more than 14 days (15 total) == * freevo-1.9.0-14 (any), since 2014-08-27 * rt3562sta-2.4.1.1_r1-15 (i686), since 2014-12-17 * rt3562sta-2.4.1.1_r1-15 (x86_64), since 2014-12-17 * acpi_call-1.1.0-17 (i686), since 2014-12-17 * tp_smapi-0.41-58 (i686), since 2014-12-17 * acpi_call-1.1.0-17 (x86_64), since 2014-12-17 * tp_smapi-0.41-58 (x86_64), since 2014-12-17 * virtualbox-modules-4.3.20-4 (i686), since 2014-12-17 * virtualbox-modules-4.3.20-4 (x86_64), since 2014-12-17 * bbswitch-0.8-21 (i686), since 2014-12-17 * r8168-8.039.00-6 (i686), since 2014-12-17 * bbswitch-0.8-21 (x86_64), since 2014-12-17 * r8168-8.039.00-6 (x86_64), since 2014-12-17 * vhba-module-20140928-1 (i686), since 2014-12-21 * vhba-module-20140928-1 (x86_64), since 2014-12-21 == Top five in signoffs in last 24 hours == 1. arodseth - 2 signoffs 2. eric - 2 signoffs

1 0

[aur-general] Signoff report for [community-testing]
by Arch Website Notification 08 Jan '15

08 Jan '15

=== Signoff report for [community-testing] === https://www.archlinux.org/packages/signoffs/ There are currently: * 0 new packages in last 24 hours * 0 known bad packages * 0 packages not accepting signoffs * 0 fully signed off packages * 21 packages missing signoffs * 15 packages older than 14 days (Note: the word 'package' as used here refers to packages as grouped by pkgbase, architecture, and repository; e.g., one PKGBUILD produces one package per architecture, even if it is a split package.) == Incomplete signoffs for [community] (19 total) == * eric-6.0.0-1 (any) 1/2 signoffs * eric-i18n-6.0.0-1 (any) 1/2 signoffs * freevo-1.9.0-14 (any) 0/2 signoffs * acpi_call-1.1.0-17 (i686) 0/1 signoffs * bbswitch-0.8-21 (i686) 0/1 signoffs * python-h5py-2.4.0-1 (i686) 0/1 signoffs * r8168-8.039.00-6 (i686) 0/1 signoffs * rt3562sta-2.4.1.1_r1-15 (i686) 0/1 signoffs * tp_smapi-0.41-58 (i686) 0/1 signoffs * vhba-module-20140928-1 (i686) 0/1 signoffs * virtualbox-modules-4.3.20-4 (i686) 0/1 signoffs * acpi_call-1.1.0-17 (x86_64) 0/2 signoffs * bbswitch-0.8-21 (x86_64) 0/2 signoffs * python-h5py-2.4.0-1 (x86_64) 0/2 signoffs * r8168-8.039.00-6 (x86_64) 0/2 signoffs * rt3562sta-2.4.1.1_r1-15 (x86_64) 0/2 signoffs * tp_smapi-0.41-58 (x86_64) 0/2 signoffs * vhba-module-20140928-1 (x86_64) 0/2 signoffs * virtualbox-modules-4.3.20-4 (x86_64) 0/2 signoffs == Incomplete signoffs for [unknown] (2 total) == * qscintilla-qt5-2.8.4-2 (i686) 0/1 signoffs * qscintilla-qt5-2.8.4-2 (x86_64) 1/2 signoffs == All packages in [community-testing] for more than 14 days (15 total) == * freevo-1.9.0-14 (any), since 2014-08-27 * rt3562sta-2.4.1.1_r1-15 (i686), since 2014-12-17 * rt3562sta-2.4.1.1_r1-15 (x86_64), since 2014-12-17 * acpi_call-1.1.0-17 (i686), since 2014-12-17 * tp_smapi-0.41-58 (i686), since 2014-12-17 * acpi_call-1.1.0-17 (x86_64), since 2014-12-17 * tp_smapi-0.41-58 (x86_64), since 2014-12-17 * virtualbox-modules-4.3.20-4 (i686), since 2014-12-17 * virtualbox-modules-4.3.20-4 (x86_64), since 2014-12-17 * bbswitch-0.8-21 (i686), since 2014-12-17 * r8168-8.039.00-6 (i686), since 2014-12-17 * bbswitch-0.8-21 (x86_64), since 2014-12-17 * r8168-8.039.00-6 (x86_64), since 2014-12-17 * vhba-module-20140928-1 (i686), since 2014-12-21 * vhba-module-20140928-1 (x86_64), since 2014-12-21 == Top five in signoffs in last 24 hours == 1. lcarlier - 4 signoffs

1 0

[aur-general] cmake does not (necessarily) honor makepkg.conf
by Que Quotion 08 Jan '15

08 Jan '15

I first came across this problem while working on mmug-qq (a project to create updated and upstream packages for various build dependencies of pcsx2) when I found that some cmake packages would not compile in 32bit with any configuration. It took some digging, but I finally determined that I had indeed exhausted every appropriate option. Something was blocking, ignoring, or removing my settings; preventing packages from being built with the parameters I specified in makepkg.conf and in the PKGBUILDs. The problem is cmake, or more specifically it's various layers of macros. Many cmake packages fail to pass CFLAGS, CXXFLAGS, and LDFLAGS through the various macros to make; some packages ignore these variables entirely. This does not appear to be intentional; I did not find code explicitly stripping away or replacing flags. I found that many of the macros just lost them somewhere; failed to transfer them to cmake variables that would be used later; or inexplicably make with no flags at all for no reason. The only way I could convince cmake packages to always use all of the flags specified in makepkg.conf and/or in the PKGBUILD was to deceive it; to force it to use compilers and a linker with the flags built in. So I created three files: gcc-flagged: /usr/bin/gcc $CFLAGS "$@" g++-flagged: /usr/bin/g++ $CXXFLAGS "$@" ld-flagged: /usr/bin/ld $LDFLAGS "$@" and added this to sources(): {gcc,g++,ld}-flagged and this to the cmake call: -DCMAKE_C_COMPILER="$srcdir"/gcc-flagged \ -DCMAKE_CXX_COMPILER="$srcdir"/g++-flagged \ -DCMAKE_LINKER="$srcdir"/ld-flagged For an example, check out my sdl2-hg-multilib packaging: https://github.com/quequotion/mmug-qq/tree/master/sdl2-hg-multilib

1 0

[aur-general] Signoff report for [community-testing]
by Arch Website Notification 07 Jan '15

07 Jan '15

=== Signoff report for [community-testing] === https://www.archlinux.org/packages/signoffs/ There are currently: * 0 new packages in last 24 hours * 0 known bad packages * 0 packages not accepting signoffs * 0 fully signed off packages * 21 packages missing signoffs * 15 packages older than 14 days (Note: the word 'package' as used here refers to packages as grouped by pkgbase, architecture, and repository; e.g., one PKGBUILD produces one package per architecture, even if it is a split package.) == Incomplete signoffs for [community] (19 total) == * eric-6.0.0-1 (any) 1/2 signoffs * eric-i18n-6.0.0-1 (any) 1/2 signoffs * freevo-1.9.0-14 (any) 0/2 signoffs * acpi_call-1.1.0-17 (i686) 0/1 signoffs * bbswitch-0.8-21 (i686) 0/1 signoffs * python-h5py-2.4.0-1 (i686) 0/1 signoffs * r8168-8.039.00-6 (i686) 0/1 signoffs * rt3562sta-2.4.1.1_r1-15 (i686) 0/1 signoffs * tp_smapi-0.41-58 (i686) 0/1 signoffs * vhba-module-20140928-1 (i686) 0/1 signoffs * virtualbox-modules-4.3.20-4 (i686) 0/1 signoffs * acpi_call-1.1.0-17 (x86_64) 0/2 signoffs * bbswitch-0.8-21 (x86_64) 0/2 signoffs * python-h5py-2.4.0-1 (x86_64) 0/2 signoffs * r8168-8.039.00-6 (x86_64) 0/2 signoffs * rt3562sta-2.4.1.1_r1-15 (x86_64) 0/2 signoffs * tp_smapi-0.41-58 (x86_64) 0/2 signoffs * vhba-module-20140928-1 (x86_64) 0/2 signoffs * virtualbox-modules-4.3.20-4 (x86_64) 0/2 signoffs == Incomplete signoffs for [unknown] (2 total) == * qscintilla-qt5-2.8.4-2 (i686) 0/1 signoffs * qscintilla-qt5-2.8.4-2 (x86_64) 1/2 signoffs == All packages in [community-testing] for more than 14 days (15 total) == * freevo-1.9.0-14 (any), since 2014-08-27 * rt3562sta-2.4.1.1_r1-15 (i686), since 2014-12-17 * rt3562sta-2.4.1.1_r1-15 (x86_64), since 2014-12-17 * acpi_call-1.1.0-17 (i686), since 2014-12-17 * tp_smapi-0.41-58 (i686), since 2014-12-17 * acpi_call-1.1.0-17 (x86_64), since 2014-12-17 * tp_smapi-0.41-58 (x86_64), since 2014-12-17 * virtualbox-modules-4.3.20-4 (i686), since 2014-12-17 * virtualbox-modules-4.3.20-4 (x86_64), since 2014-12-17 * bbswitch-0.8-21 (i686), since 2014-12-17 * r8168-8.039.00-6 (i686), since 2014-12-17 * bbswitch-0.8-21 (x86_64), since 2014-12-17 * r8168-8.039.00-6 (x86_64), since 2014-12-17 * vhba-module-20140928-1 (i686), since 2014-12-21 * vhba-module-20140928-1 (x86_64), since 2014-12-21 == Top five in signoffs in last 24 hours == 1. anatolik - 1 signoffs

1 0

[aur-general] Orphan packages, Policy on bots
by David Phillips 07 Jan '15

07 Jan '15

Hi all, I've been looking at writing a small bot which will crawl over orphaned packages' PKGBUILDs, performing analysis and gathering stats. For example, I'm really keen on making an attempt to clean a bunch of them up. 25% of the 53587 packages in the AUR today are orphans and, like many others, I'd like to see this number decreased. In the past, I have manually gone down the list of orphans, but that's just horrible and slow (also, can't get my browser to do HTTP head requests). So naturally, I started writing a bot. I did start thinking about having the bot comment on packages with dead end sources, but soon realised this would complicate things too much if it were to stop repeating itself each time it is run etc. Being able to pull various lists (for humans, not bots, to act up) out of a magic hat. As a random example, it'd be useful to pull out a list of packages which: * Are orhpans * Have less than five votes * Have dead end sources * Haven't been updated in the last year So we could send a couple of people to, eg, adopt or file appropriate requests. So anyway, I've seen wiki bots doing their thing on our wiki, but what's the policy on AUR bots? -- Four word witty remark

4 9

[aur-general] More trolling
by Alexandru Ianu 07 Jan '15

07 Jan '15

>Hi, > >The real Allan just removed the account. I'm now removing all his >comments. > >Lukas, is there an option to remove an account and all the comments made >by that account? > >-- >Jelle van der Waa Hi, The troll hit my account as well. The only lasting damage is a comment on the package: yaourt-gui-manjaro >AllanMcrea comment >2015-01-03 00:20 >WTF this does not work with pacman < 4.2 get off your butt and fix >this crap Thanks, Alexandru Ianu

8 11

[aur-general] Rules about providing "compiled" documentation
by JoKoT3 06 Jan '15

06 Jan '15

Hello, I maintain the package gnuplot-nox [1], which is a low dependency version of extra package gnuplot [2]. Until recently, I was building and installing the gnuplot.info file (texinfo format) using file gnuplot.texi which was provided in the archive. (generation goes this way : gnuplot.doc -> gnuplot.texi -> gnuplot.info). The latest release of gnuplot (5.0) does not provide the intermediate texi file anymore. Without it, I cannot generate the info file directly, I have to use emacs to generate the texi file. This bring a new build dependency to the package. I'm looking for advises on how to deal with the situation : 1/ Can I provide a locally built gnuplot.info in the package ? Does this respect the standard ? 2/ Should I give up on providing the info file ? 3/ Should I keep the emacs build-deps and keep building the info file ? Not really low-dependency... Also note that generating the info file is not a default target of the Makefile since version 4.6.4. The only other "usable" source of documentation I can provide with the package is the gnuplot.pdf file which is still present in the archive. Regards, [1] https://aur.archlinux.org/packages/gnuplot-nox/ [2] https://www.archlinux.org/packages/extra/x86_64/gnuplot/

3 3

Re: [aur-general] Forgotten email address
by ioanmoldovan 06 Jan '15

06 Jan '15

Yes, i haven't used my account in months and forgot it. Sorry! Sent from Samsung MobileTaylor Lookabaugh <jesus.christ.i.love(a)gmail.com> wrote:On 01/06/2015 12:51 AM, Ioan Moldovan wrote: > Also my username is: ioanm > > On Tue, Jan 06, 2015 at 08:48:48AM +0200, Ioan Moldovan wrote: >> Hi, my name is Ioan Moldovan, and I have forgotten my aur email. Can you >> please help me? So you forgot your password too I suppose? You should be able to login and know which email is connected to the account if you remember your password. -- Taylor Lookabaugh "I consider my ability to arouse enthusiasm among my people, the greatest asset I possess, and the way to develop the best that is in a person is by appreciation and encouragement. There is nothing else that so kills the ambitions of a person as criticisms from superiors. I never criticize any-one. I believe in giving a person incentive to work. So I am anxious to praise but loath to find fault. If I like anything, I am hearty in my approbation and lavish in my praise." --Charles Schwab

1 0

Re: [aur-general] Forgotten email address
by ioanmoldovan 06 Jan '15

06 Jan '15

Yes, i'm sorry Sent from Samsung MobileTaylor Lookabaugh <jesus.christ.i.love(a)gmail.com> wrote:On 01/06/2015 12:51 AM, Ioan Moldovan wrote: > Also my username is: ioanm > > On Tue, Jan 06, 2015 at 08:48:48AM +0200, Ioan Moldovan wrote: >> Hi, my name is Ioan Moldovan, and I have forgotten my aur email. Can you >> please help me? So you forgot your password too I suppose? You should be able to login and know which email is connected to the account if you remember your password. -- Taylor Lookabaugh "I consider my ability to arouse enthusiasm among my people, the greatest asset I possess, and the way to develop the best that is in a person is by appreciation and encouragement. There is nothing else that so kills the ambitions of a person as criticisms from superiors. I never criticize any-one. I believe in giving a person incentive to work. So I am anxious to praise but loath to find fault. If I like anything, I am hearty in my approbation and lavish in my praise." --Charles Schwab

1 0