=== 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
* 13 packages missing signoffs
* 3 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] (11 total) ==
* freevo-1.9.0-14 (any)
0/2 signoffs
* gdal-1.11.1-3 (i686)
0/1 signoffs
* performous-1.0-1 (i686)
0/1 signoffs
* python-h5py-2.3.1-3 (i686)
0/1 signoffs
* python-pytables-3.1.1-4 (i686)
0/1 signoffs
* vtk-6.1.0-1 (i686)
0/1 signoffs
* gdal-1.11.1-3 (x86_64)
0/2 signoffs
* performous-1.0-1 (x86_64)
0/2 signoffs
* python-h5py-2.3.1-3 (x86_64)
0/2 signoffs
* python-pytables-3.1.1-4 (x86_64)
0/2 signoffs
* vtk-6.1.0-1 (x86_64)
0/2 signoffs
== Incomplete signoffs for [unknown] (2 total) ==
* packagekit-qt-0.9.2-2 (i686)
0/1 signoffs
* packagekit-qt-0.9.2-2 (x86_64)
0/2 signoffs
== All packages in [community-testing] for more than 14 days (3 total) ==
* freevo-1.9.0-14 (any), since 2014-08-27
* packagekit-qt-0.9.2-2 (i686), since 2014-09-29
* packagekit-qt-0.9.2-2 (x86_64), since 2014-09-29
== Top five in signoffs in last 24 hours ==
1. fyan - 3 signoffs
2. bpiotrowski - 2 signoffs
[ Copying aur-general for other opnions and get clarification on AUR
rules out there ]
Hey Jonathan,
Thanks for maintaining AUR and keeping the Arch ecosystem healthy. Some
honest questions/comments regarding the deletion of the AUR package
customizepkg-ald:
The package was a patched version of customizepkg.
There are thousands of AUR packages that are variants of other packages
and I can't see any problem with that. In my understanding that's part
of what AUR is for. Is it not?
It's been customary for AUR deletions, orphanings etc. to have a two
weeks grace period. Should that not also apply to TUs?
The .tar.gz that you mentioned that violated the "no binaries on AUR"
rule contained nothing but ASCII files (as does customizepk¹). If I
unzip the tarball and re-upload it, does that not violate the rule? What
if I also untar it and upload each text file individually?
Cheers, Daniel
¹ https://aur.archlinux.org/packages/customizepkg/
On Di, 2014-11-25 at 18:52 +0000, notify(a)aur.archlinux.org wrote:
> from https://aur.archlinux.org//pkgbase/customizepkg-ald/
> jsteel wrote:
>
> Ah, I just realised this is an intentional duplicate of customizepkg;
> please don't submit duplicate packages, submit an orphan request
> instead. Deleting.
>
> ---
> If you no longer wish to receive notifications about this package,
> please go the the above package page and click the UnNotify button.
=== Signoff report for [community-testing] ===
https://www.archlinux.org/packages/signoffs/
There are currently:
* 2 new packages in last 24 hours
* 0 known bad packages
* 0 packages not accepting signoffs
* 0 fully signed off packages
* 15 packages missing signoffs
* 3 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 (2 total) ==
* icecast-2.4.1-1 (i686)
* icecast-2.4.1-1 (x86_64)
== Incomplete signoffs for [community] (13 total) ==
* freevo-1.9.0-14 (any)
0/2 signoffs
* gdal-1.11.1-3 (i686)
0/1 signoffs
* icecast-2.4.1-1 (i686)
0/1 signoffs
* performous-1.0-1 (i686)
0/1 signoffs
* python-h5py-2.3.1-3 (i686)
0/1 signoffs
* python-pytables-3.1.1-4 (i686)
0/1 signoffs
* vtk-6.1.0-1 (i686)
0/1 signoffs
* gdal-1.11.1-3 (x86_64)
0/2 signoffs
* icecast-2.4.1-1 (x86_64)
0/2 signoffs
* performous-1.0-1 (x86_64)
0/2 signoffs
* python-h5py-2.3.1-3 (x86_64)
0/2 signoffs
* python-pytables-3.1.1-4 (x86_64)
0/2 signoffs
* vtk-6.1.0-1 (x86_64)
0/2 signoffs
== Incomplete signoffs for [unknown] (2 total) ==
* packagekit-qt-0.9.2-2 (i686)
0/1 signoffs
* packagekit-qt-0.9.2-2 (x86_64)
0/2 signoffs
== All packages in [community-testing] for more than 14 days (3 total) ==
* freevo-1.9.0-14 (any), since 2014-08-27
* packagekit-qt-0.9.2-2 (i686), since 2014-09-29
* packagekit-qt-0.9.2-2 (x86_64), since 2014-09-29
== Top five in signoffs in last 24 hours ==
Hello,
I just accidentally uploaded a miss named package, I have re-uploaded a
version with correct naming, but the old is still here to be removed:
It is called "android-samples-5.0".
Thank you very much in advance!
Best regards,
Christoph Bayer
The the default configuration under ArchLinux and DEVICE partitions in
mdadm.conf, mdadm and the mdadm mkinitcpio hook fail to load the
raid10 kernel module automatically, and as a result raid10 arrays fail
to load on boot in Arch.
My temporary workaround is to include the raid10 kernel module in the
mkinitcpio.conf MODULES= list, it could also be included in
/etc/modules-load.d/*.conf, but this should not be necessary, and is
currently not necessary for raid1 arrays. I do not think this is an
upstream problem since my LFS and Gentoo boxes do load the correct
(raid10) kernel module without any specific configuration to do so.
Has anyone else replicated this behavior?
Suggestions:
- Preferred: Make the initcpio hook/mdadm udev rules/whatever loads
raid1.ko normally also detect raid10 (and raid5, raid6, ...) arrays
properly.
- Alternatively: Add a section to the SW RAID wiki page describing how
to make the module load persist on boot
(https://wiki.archlinux.org/index.php/Software_RAID_and_LVM#Load_kernel_modu…)
Ido
Through searching, I've found discussions about people adding
unsupported architectures (specifically arm and ppc) to their current
i686/x86_64 PKGBUILDs. Nobody has a problem with that (I don't,
either). What I haven't found is any discussion about packages that are
*exclusively* for one of these architectures. Is this something that's
allowed or not?
Doug