=== 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
* 17 packages missing signoffs
* 2 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] (17 total) ==
* salt-2015.5.3-1 (any)
0/2 signoffs
* acpi_call-1.1.0-31 (i686)
0/1 signoffs
* bbswitch-0.8-33 (i686)
0/1 signoffs
* lightdm-1:1.14.0-4 (i686)
0/1 signoffs
* r8168-8.040.00-3 (i686)
0/1 signoffs
* rt3562sta-2.4.1.1_r2-9 (i686)
0/1 signoffs
* tp_smapi-0.41-70 (i686)
0/1 signoffs
* vhba-module-20140928-14 (i686)
0/1 signoffs
* virtualbox-modules-4.3.28-3 (i686)
0/1 signoffs
* acpi_call-1.1.0-31 (x86_64)
0/2 signoffs
* bbswitch-0.8-33 (x86_64)
0/2 signoffs
* lightdm-1:1.14.0-4 (x86_64)
0/2 signoffs
* r8168-8.040.00-3 (x86_64)
0/2 signoffs
* rt3562sta-2.4.1.1_r2-9 (x86_64)
0/2 signoffs
* tp_smapi-0.41-70 (x86_64)
0/2 signoffs
* vhba-module-20140928-14 (x86_64)
0/2 signoffs
* virtualbox-modules-4.3.28-3 (x86_64)
0/2 signoffs
== All packages in [community-testing] for more than 14 days (2 total) ==
* lightdm-1:1.14.0-4 (i686), since 2015-06-26
* lightdm-1:1.14.0-4 (x86_64), since 2015-06-26
== Top five in signoffs in last 24 hours ==
1. bisson - 6 signoffs
2. foutrelis - 3 signoffs
3. seblu - 1 signoffs
Hi,
has somebody an idea what to do?
I added a comment to https://aur4.archlinux.org/packages/shutter-bzr/ :
"I had 1272-3 from AUR 3 installed and it worked, but seemingly related to pearl upgrades it doesn't work anymore.
After rebuilding from AUR 3 first and then from AUR 4 shutter still doesn't run.
$ shutter
/usr/bin/perl: symbol lookup error: /usr/lib/perl5/vendor_perl/auto/List/Util/Util.so: undefined symbol: Perl_xs_apiversion_bootcheck
Rebuilding perl-scalar-list-utils from AUR 3 git fails. The PKGBUILD isn't provided by AUR 3, AUR 4 or the official repositories.
$ makepkg -s --skipchecksums
==> Making package: perl-scalar-list-utils 1.38-3 (Thu Jul 9 18:02:07 CEST 2015)
==> Extracting sources...
-> Extracting Scalar-List-Utils-1.38.tar.gz with bsdtar
==> Starting build()...
Checking if your kit is complete...
/usr/bin/perl: symbol lookup error: /usr/lib/perl5/vendor_perl/auto/List/Util/Util.so: undefined symbol: Perl_xs_apiversion_bootcheck
==> ERROR: A failure occurred in build().
Aborting...
$ pacman -Qo /usr/lib/perl5/vendor_perl/auto/List/Util/Util.so
/usr/lib/perl5/vendor_perl/auto/List/Util/Util.so is owned by perl-scalar-list-utils 1.38-2"
This seems to be an issue for several apps, but the only recommendation I
found by a web research was the hint to downgrade pearl packages.
Regards,
Ralf
Hi,
it is July 8th (anywhere on earth) now, so I just disowned all packages
that were not uploaded to aur4.archlinux.org yet.
Feel free to adopt and resubmit your favorite packages!
Regards,
Lukas
I am the owner of python2-hglib, and I would like to submit a PKGBUILD that
builds both python2 and python3 packages, but cannot due to the fact that
python2-hglib is being rejected by the git hook on aur4.archlinux.org.
I already submitted this PKGBUILD, but had messed up the naming of the
package, and only noticed this blacklist issue when I tried to correct the
issue.
Can I get the blacklist removed so that I can submit my corrected PKGBUILD
providing both python-hglib and python2-hglib?
--
-Erik
"For me, it is far better to grasp the universe as it really is than to
persist in delusion, however satisfying and reassuring." -- Carl Sagan
Hello,
I am importing a PKGBUILD for something that has only a binary release.
More specifically, a binary release for i686 and another for x86_64.
In the old AUR, I was packaging it using an if clause to choose which
release to download depending on the architecture -- this way, I can
have a single package for both architectures. More or less like this:
if [ ${CARCH} = 'x86_64' ]; then
source=("http://example.com/release-${pkgver}-x86_64.tar.gz")
md5sums=('00112233445566778899aabbccddeeff')
else
source=("http://example.com/release-${pkgver}-i386.tar.gz")
md5sums=('ffeeddccbbaa99887766554433221100')
fi
Running mksrcinfo fails with the error:
/path/PKGBUILD: line XX: [: =: unary operator expected
"line XX" points to the line containing the if.
Are there some guildelines for packaging something like this?
How could I make mksrcinfo work?
Is there any way to generate the .SRCINFO file manually to conform to
the dual-binary release described above?
(or... should I not be doing this at all?)
--
Rudy
=== Signoff report for [community-testing] ===
https://www.archlinux.org/packages/signoffs/
There are currently:
* 1 new package in last 24 hours
* 0 known bad packages
* 0 packages not accepting signoffs
* 0 fully signed off packages
* 17 packages missing signoffs
* 0 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.)
== New packages in [community-testing] in last 24 hours (1 total) ==
* salt-2015.5.3-1 (any)
== Incomplete signoffs for [community] (17 total) ==
* salt-2015.5.3-1 (any)
0/2 signoffs
* acpi_call-1.1.0-31 (i686)
0/1 signoffs
* bbswitch-0.8-33 (i686)
0/1 signoffs
* lightdm-1:1.14.0-4 (i686)
0/1 signoffs
* r8168-8.040.00-3 (i686)
0/1 signoffs
* rt3562sta-2.4.1.1_r2-9 (i686)
0/1 signoffs
* tp_smapi-0.41-70 (i686)
0/1 signoffs
* vhba-module-20140928-14 (i686)
0/1 signoffs
* virtualbox-modules-4.3.28-3 (i686)
0/1 signoffs
* acpi_call-1.1.0-31 (x86_64)
0/2 signoffs
* bbswitch-0.8-33 (x86_64)
0/2 signoffs
* lightdm-1:1.14.0-4 (x86_64)
0/2 signoffs
* r8168-8.040.00-3 (x86_64)
0/2 signoffs
* rt3562sta-2.4.1.1_r2-9 (x86_64)
0/2 signoffs
* tp_smapi-0.41-70 (x86_64)
0/2 signoffs
* vhba-module-20140928-14 (x86_64)
0/2 signoffs
* virtualbox-modules-4.3.28-3 (x86_64)
0/2 signoffs
== Top five in signoffs in last 24 hours ==
There's a PKGBUILD[1] on the AUR that downloads a binary that is illegal
to distribute (due to licensing, it may only be distributed in source
form).
IMHO, it's a bit of a grey area if the PKGBUILD is legal or not (I
believe it is not in some jurisdictions), but anyone running it is
receiving illegal content, so I don't think we should keep it around.
I put up a deletion request[2] for this, and the response was "The AUR
does not distribute binaries.".
While this is true, it does distribute the PKGBUILD for downloading the
ilegal binary. This is not a case of "the package can be used to do
something possibly illegal", this is a case of "this script was tailored
exclusively and with the sole objective of distributing something
illegal, and can only be used for that".
[1]: https://aur4.archlinux.org/pkgbase/telegram-desktop/
[2]:
https://lists.archlinux.org/pipermail/aur-requests/2015-July/007698.html
--
Hugo Osvaldo Barrera