Re: [aur-general] Prefered way to create users/groups and handle files ownership
On Mon, Jan 27, 2014 at 2:44 PM, Emil Lundberg wrote: > Of course this isn't a problem if the package is only in the AUR, but > it eliminates the option to prebuild the package (for inclusion in the > official repositories, for instance). Sorry for double posting, it struck me right after sending the last message that this also won't be a problem when there is a generally accepted standard uid/gid for the particular user/group in question. /Emil Lundberg
Re: [aur-general] Prefered way to create users/groups and handle files ownership
On Mon, Jan 27, 2014 at 5:35 AM, Jeremy Audet wrote:
> As for a better solution? Hmm. `install` (and probably other tools too) can
> reference user and group names directly. Thus, this:
>
>> install -o141 -g141 -dm750 "${pkgdir}/var/log/inspircd"
>
> Could also be written as this:
>
>> install -o inspircd -g inspircd -dm750 "${pkgdir}/var/log/inspircd"
The problem with that is that the uid/gid for the permissions will be
computed on the machine where the package is built, and there is no
guarantee that the same uid/gid has the same name on another machine.
Of course this isn't a problem if the package is only in the AUR, but
it eliminates the option to prebuild the package (for inclusion in the
official repositories, for instance).
If you want an example, I've attached a simple bash script that
demonstrates the behaviour by referencing "uidgidtestuser1" when
building the package, then renaming that user to "uidgidtestuser2".
The script will output a PKGBUILD, build the package, run sudo and
manipulate users and install/uninstall the package, so MAKE SURE YOU
READ THE SCRIPT before you run it. I take no responsibility for any
damage caused by running it.
/Emil Lundberg
Re: [aur-general] Prefered way to create users/groups and handle files ownership
> The reason why permissions should be set in the PKGBUILD is because that
> way pacman can track them.
Interesting. I didn't know Pacman could do that. The phrases "UID", "uid"
and "gid" do not appear in the man pages for pacman or pkgbuild. Is this
undocumented behaviour?
> Then it's up to the maintainer to choose
> UIDs/GIDs that do not conflict with official packages, and to the user to
> check that they don't already use that particular UID/GID ,before
> installing an AUR package.
Ick. I think that's an unnecessary and unreasonable expectation that
results in a more fragile and unmaintainble system.
As for a better solution? Hmm. `install` (and probably other tools too) can
reference user and group names directly. Thus, this:
> install -o141 -g141 -dm750 "${pkgdir}/var/log/inspircd"
Could also be written as this:
> install -o inspircd -g inspircd -dm750 "${pkgdir}/var/log/inspircd"
--Jeremy
Re: [aur-general] Delete requests: Old python libs
> But anyway, the package had an incorrect name. And I think that packages into > AUR, such as this one, must not be split packages. I agree. Python 2 and Python 3 packages should be separate, in my opinion. One should not need to install Python 3 to get a Python 2 package, and vice versa. --Jeremy
[aur-general] Remove some mingw-w64 packages
Could you remove the following packages. They are no longer needed since there is a package providing the static and shared libraries. https://aur.archlinux.org/packages/mingw-w64-allegro-static/ https://aur.archlinux.org/packages/mingw-w64-gmp-static/ https://aur.archlinux.org/packages/mingw-w64-libmpc-static/ https://aur.archlinux.org/packages/mingw-w64-mpfr-static/ Package providing the static package. (Do not remove these. They are for your reference) https://aur.archlinux.org/packages/mingw-w64-allegro/ https://aur.archlinux.org/packages/mingw-w64-gmp/ https://aur.archlinux.org/packages/mingw-w64-libmpc/ https://aur.archlinux.org/packages/mingw-w64-mpfr/ Also could you remove https://aur.archlinux.org/packages/mingw-w64-qt5-base-internal-angle/ It was built in hopes that it would fix a problem. It ended up having the same problem as using the external angle. -ant32 http://mingw-w64-archlinux.sourceforge.net/
Re: [aur-general] Merge request
On Sat, Jan 25, 2014 at 09:51:11PM +0100, Maxime Gauduin wrote: > On Sat, Jan 25, 2014 at 6:02 PM, David J. Haines wrote: > > > Hi all, > > > > I just took over pioneer and pioneer-git. The way upstream has been > > releasing things has made it that, under the prior maintainer, > > pioneer-git was really using upstream's versioning, while pioneer > > languished under upstream's old versioning system as "alpha"-something. > > > > Please merge pioneer-git > > (https://aur.archlinux.org/packages/pioneer-git/) into pioneer > > (https://aur.archlinux.org/packages/pioneer/) so that I can continue > > forward with just the one. > > > > Thanks! > > > > -- > > David J. Haines > > djhai...@gmx.com > > 0xAFB3D16D - F929 270F B7C3 78AE A741 434F A7C6 F264 AFB3 D16C > > > > I don't think a merge is necessary here. Those 2 packages can coexist, just > update pioneer so that it uses the new versioning. BTW, pioneer-git should > be updated to use the not so new now VCS source array capabilities. > > Cheers, > -- > Maxime Given the freqeuency of releases upstream (in their own words: "We release a new version almost every day."), I don't see much of a need for both. If you're unwilling to merge, I'd request instead that pioneer-git be deleted. Thanks, -- David J. Haines djhai...@gmx.com 0xAFB3D16D - F929 270F B7C3 78AE A741 434F A7C6 F264 AFB3 D16C
[aur-general] Orphan request: craftbukkit-git
Hi, could a TU please orphan craftbukkit-git[1]. I've contacted the maintainer 2 weeks ago and didn't got a response. [1] https://aur.archlinux.org/packages/craftbukkit-git --- Yours sincerely Vincent Post signature.asc Description: OpenPGP digital signature
Re: [aur-general] Prefered way to create users/groups and handle files ownership
Maxime Gauduin wrote: >The reason why permissions should be set in the PKGBUILD is because that >way pacman can track them. Then it's up to the maintainer to choose >UIDs/GIDs that do not conflict with official packages, and to the user to >check that they don't already use that particular UID/GID ,before >installing an AUR package. > >Cheers, >-- >Maxime I just want to add that I think hard-coding UIDs and GIDs is a very bad idea. I would expect them to vary across systems. No, I do not have a better suggestion. Regards, Xyne
Re: [aur-general] TU application, sponsored by Lukas Fleischer
On 2014-01-24 19:53 +0100 carstene1ns wrote: *snip* > several good points *snip* Becoming a TU is not like joining Cosa Nostra... it's not always for life. Some TUs inevitably find that real-life obligations eliminate the free time they once had to maintain packages and so the quality drops. We are supposed to keep an eye on each other and discuss problems that we see. In the worst case we also have removal procedures. Unfortunately, nobody ever really wants to be the bad guy calling out others on bad habits. TUs are not exempt from having their packages orphaned either. If a package has been flagged out-of-date for weeks/months and the TU fails to respond via email then you can send an orphan request to this list. It should also incite a discussion about the TU in question. I hope that Dragonlord and speps will respond to your points and either fix or orphan their flagged packages. I can also honestly say that I would oppose an application from someone with 51 flagged packages, so I do not believe that I am inconsistent in my remarks about the current application. Regards, Xyne
[aur-general] Signoff report for [community-testing]
=== Signoff report for [community-testing] === https://www.archlinux.org/packages/signoffs/ There are currently: * 8 new packages in last 24 hours * 0 known bad packages * 0 packages not accepting signoffs * 3 fully signed off packages * 58 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 (8 total) == * ruby-mail-2.5.4-4 (any) * ruby-mime-types-2.0-4 (any) * ruby-polyglot-0.3.3-5 (any) * ruby-term-ansicolor-1.2.2-5 (any) * ruby-tins-0.13.1-2 (any) * ruby-treetop-1.4.15-5 (any) * ruby-iconv-1.0.4-2 (i686) * ruby-iconv-1.0.4-2 (x86_64) == Incomplete signoffs for [community] (54 total) == * goagent-3.1.5-1 (any) 0/2 signoffs * ruby-mail-2.5.4-4 (any) 0/2 signoffs * ruby-mime-types-2.0-4 (any) 0/2 signoffs * ruby-pkgconfig-1.1.5-1 (any) 0/2 signoffs * ruby-polyglot-0.3.3-5 (any) 0/2 signoffs * ruby-rack-1.5.2-3 (any) 0/2 signoffs * ruby-term-ansicolor-1.2.2-5 (any) 0/2 signoffs * ruby-tins-0.13.1-2 (any) 0/2 signoffs * ruby-treetop-1.4.15-5 (any) 0/2 signoffs * rubyripper-0.6.2-5 (any) 0/2 signoffs * taskjuggler3-3.5.0-7 (any) 0/2 signoffs * clearsilver-0.10.5-13 (i686) 0/1 signoffs * darktable-1.4-3 (i686) 0/1 signoffs * gimp-ufraw-0.19-3 (i686) 0/1 signoffs * kphotoalbum-4.4-4 (i686) 0/1 signoffs * krename-4.0.9-3 (i686) 0/1 signoffs * libextractor-1.0.1-5 (i686) 0/1 signoffs * libgexiv2-0.7.0-2 (i686) 0/1 signoffs * luminancehdr-2.3.1-5 (i686) 0/1 signoffs * marisa-0.2.4-3 (i686) 0/1 signoffs * nomacs-1.6.2-3 (i686) 0/1 signoffs * notmuch-0.17-1 (i686) 0/1 signoffs * obexftp-0.24-2 (i686) 0/1 signoffs * passenger-4.0.21-3 (i686) 0/1 signoffs * pinot-1.06-3 (i686) 0/1 signoffs * python2-exiv2-0.3.2-3 (i686) 0/1 signoffs * rawstudio-2.0-11 (i686) 0/1 signoffs * ruby-iconv-1.0.4-2 (i686) 0/1 signoffs * ruby-ncurses-1.3.1-6 (i686) 0/1 signoffs * uwsgi-2.0-3 (i686) 0/1 signoffs * xmms2-0.8DrO_o-23 (i686) 0/1 signoffs * clearsilver-0.10.5-13 (x86_64) 0/2 signoffs * darktable-1.4-3 (x86_64) 0/2 signoffs * gimp-ufraw-0.19-3 (x86_64) 0/2 signoffs * kphotoalbum-4.4-4 (x86_64) 0/2 signoffs * krename-4.0.9-3 (x86_64) 0/2 signoffs * libextractor-1.0.1-5 (x86_64) 0/2 signoffs * libgexiv2-0.7.0-2 (x86_64) 0/2 signoffs * luminancehdr-2.3.1-5 (x86_64) 0/2 signoffs * marisa-0.2.4-3 (x86_64) 0/2 signoffs * nomacs-1.6.2-3 (x86_64) 0/2 signoffs * notmuch-0.17-1 (x86_64) 0/2 signoffs * obexftp-0.24-2 (x86_64) 0/2 signoffs * passenger-4.0.21-3 (x86_64) 0/2 signoffs * pinot-1.06-3 (x86_64) 0/2 signoffs * python2-exiv2-0.3.2-3 (x86_64) 0/2 signoffs * rawstudio-2.0-11 (x86_64) 0/2 signoffs * ruby-cairo-1.12.8-1 (x86_64) 1/2 signoffs * ruby-gtk2-2.1.0-2 (x86_64) 1/2 signoffs * ruby-gtk3-2.1.0-2 (x86_64) 1/2 signoffs * ruby-iconv-1.0.4-2 (x86_64) 0/2 signoffs * ruby-ncurses-1.3.1-6 (x86_64) 0/2 signoffs * uwsgi-2.0-3 (x86_64) 0/2 signoffs * xmms2-0.8DrO_o-23 (x86_64) 0/2 signoffs == Incomplete signoffs for [unknown] (4 total) == * libnftnl-1.0.0-1 (i686) 0/1 signoffs * nftables-0.099-1 (i686) 0/1 signoffs * libnftnl-1.0.0-1 (x86_64) 0/2 signoffs * nftables-0.099-1 (x86_64) 0/2 signoffs == Completed signoffs (3 total) == * ruby-cairo-1.12.8-1 (i686) * ruby-gtk2-2.1.0-2 (i686) * ruby-gtk3-2.1.0-2 (i686) == Top five in signoffs in last 24 hours == 1. lcarlier - 10 signoffs 2. eric - 5 signoffs 3. djgera - 4 signoffs 4. tomegun - 1 signoffs
