Re: [aur-general] Fwd: wmnd AUR package update
On Saturday, July 20, 2013 23:06:02 SanskritFritz wrote: > Please orphan the wmnd [1] package for me, it is outdated and I'm > willing to maintain it. I have emailed the current maintainer almost a > month ago and have received no answer. > Thanks in advance. > > [1] https://aur.archlinux.org/packages/wmnd/ > > -- Forwarded message -- > From: SanskritFritz > Date: Mon, Jun 24, 2013 at 11:19 PM > Subject: wmnd AUR package update > To: ferna...@zerial.org > > > Hi, would you please update the wmnd package of yours. > I sent an improved PKGBULD to the comments page. > Thanks Disowned, thanks. Regards, Felix Yan signature.asc Description: This is a digitally signed message part.
Re: [aur-general] Merge request
On Saturday, July 20, 2013 21:51:26 Jerome Leclanche wrote: > lolcode-git -> lci-git > > lci is the newer (same other, the other recommends using lci instead). I > updated the pkgbuild and they now build the same thing, though > lolcode-git's pkgbuild is more up to date. > > https://aur.archlinux.org/packages/lolcode-git/ > https://aur.archlinux.org/packages/lci-git/ > > J. Leclanche Merged, thanks. Regards, Felix Yan signature.asc Description: This is a digitally signed message part.
Re: [aur-general] request merge/delete vapoursynth-svn to vapoursynth-git
On Saturday, July 20, 2013 20:13:23 SpinFlo wrote: > please merge/delete: > > https://aur.archlinux.org/packages/vapoursynth-svn/ > into > https://aur.archlinux.org/packages/vapoursynth-git/ > > sources move from svn to git Merged, thanks. Regards, Felix Yan signature.asc Description: This is a digitally signed message part.
Re: [aur-general] uuid
On 07/20/2013 02:56 PM, Daniel Wallace wrote: > Don deJuan wrote: > > I was the maintainer for uuid and just noticed it was orphaned and uuid > > is in community, or I did not realize it was there before. But just > > curious I never got an email about the package going to be orphaned or > > anything like that. Should the package[1] be deleted from AUR all > > together now? > > > Thanks > > > [1]https://aur.archlinux.org/packages/uuid/ > > Don't delete it yet, I moved it to community when I was packaging > uwsgi in community testing. And I am not sure if uuid is needed for > what I want yet. > > I accidentally disowned it last night and tried to send you an email > last night to readopt it. > -- > Sent from my Android Phone. > Daniel Wallace > Arch Linux Trusted User > GTManfred Also curious why was it pushed to community and not community-testing if you are "testing" out if you need it with a package that is in community-testing? I get your dir layout changes but removing the perl flag sucked as it broke two packages I use, one is in the AUR, and I know other packages in AUR that require it, just no clue what their status is other than the one I maintain.
Re: [aur-general] uuid
On 07/20/2013 02:56 PM, Daniel Wallace wrote: > Don deJuan wrote: > > I was the maintainer for uuid and just noticed it was orphaned and uuid > > is in community, or I did not realize it was there before. But just > > curious I never got an email about the package going to be orphaned or > > anything like that. Should the package[1] be deleted from AUR all > > together now? > > > Thanks > > > [1]https://aur.archlinux.org/packages/uuid/ > > Don't delete it yet, I moved it to community when I was packaging > uwsgi in community testing. And I am not sure if uuid is needed for > what I want yet. > > I accidentally disowned it last night and tried to send you an email > last night to readopt it. > -- > Sent from my Android Phone. > Daniel Wallace > Arch Linux Trusted User > GTManfred Can you please make the following change in your PKGBUILD so you do not break packages that need the perl uuid. Add back in the --with-perl to ./configure please Thanks.
Re: [aur-general] uuid
On 07/20/2013 02:56 PM, Daniel Wallace wrote: > Don deJuan wrote: > > I was the maintainer for uuid and just noticed it was orphaned and uuid > > is in community, or I did not realize it was there before. But just > > curious I never got an email about the package going to be orphaned or > > anything like that. Should the package[1] be deleted from AUR all > > together now? > > > Thanks > > > [1]https://aur.archlinux.org/packages/uuid/ > > Don't delete it yet, I moved it to community when I was packaging > uwsgi in community testing. And I am not sure if uuid is needed for > what I want yet. > > I accidentally disowned it last night and tried to send you an email > last night to readopt it. > -- > Sent from my Android Phone. > Daniel Wallace > Arch Linux Trusted User > GTManfred Got ya no worries I will re-adopt the package, just noticed I got the update in my normal arch updates and it broke another package for me since it was made against the one in the AUR. Let me know if it ends up staying in community and then I will post to get it deleted. Thank you for your time.
Re: [aur-general] uuid
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Don deJuan wrote: >I was the maintainer for uuid and just noticed it was orphaned and uuid >is in community, or I did not realize it was there before. But just >curious I never got an email about the package going to be orphaned or >anything like that. Should the package[1] be deleted from AUR all >together now? > >Thanks > >[1]https://aur.archlinux.org/packages/uuid/ Don't delete it yet, I moved it to community when I was packaging uwsgi in community testing. And I am not sure if uuid is needed for what I want yet. I accidentally disowned it last night and tried to send you an email last night to readopt it. - -- Sent from my Android Phone. Daniel Wallace Arch Linux Trusted User GTManfred -BEGIN PGP SIGNATURE- Version: APG v1.0.8 iQFUBAEBCAA+BQJR6weVNxxEYW5pZWwgV2FsbGFjZSAoZ3RtYW5mcmVkKSA8ZGFu aWVsLndhbGxhY2VAZ2F0ZWNoLmVkdT4ACgkQX6XlVE8BDUiZZAf/SZKljqq1eC4A D2eWIR/9EYTi+255HsqtE4vrOKCsWW6V5Yq8x5B9Pi9kZB6lkksXr6lX9M2emuUC WFZMRWpv8DM7xuVTOy5syVwcSukOnCxm08xJjP/3hYSeLRJLjRnULhJo3H4tClF9 KALXwk1erjbEMUrA73GINldYJRxbxuALNkH3HxasRzpeDVwEkgLXIpz4sLgtj8er NOEPLUVwMzBMCeSYLgs/h3LFlBwxMhtH+H7KtLgPhuhCjfUTIVzBWHJSZW8cUAiY zj6YRcU/pvuqnlOT1Csm7tbr7E7nFGV9miThrJi7krjeXoleByxOmn7+zHzdGVHF wbERRUShRA== =QOWL -END PGP SIGNATURE-
[aur-general] Fwd: wmnd AUR package update
Please orphan the wmnd [1] package for me, it is outdated and I'm willing to maintain it. I have emailed the current maintainer almost a month ago and have received no answer. Thanks in advance. [1] https://aur.archlinux.org/packages/wmnd/ -- Forwarded message -- From: SanskritFritz Date: Mon, Jun 24, 2013 at 11:19 PM Subject: wmnd AUR package update To: ferna...@zerial.org Hi, would you please update the wmnd package of yours. I sent an improved PKGBULD to the comments page. Thanks
[aur-general] uuid
I was the maintainer for uuid and just noticed it was orphaned and uuid is in community, or I did not realize it was there before. But just curious I never got an email about the package going to be orphaned or anything like that. Should the package[1] be deleted from AUR all together now? Thanks [1]https://aur.archlinux.org/packages/uuid/
[aur-general] Merge request
lolcode-git -> lci-git lci is the newer (same other, the other recommends using lci instead). I updated the pkgbuild and they now build the same thing, though lolcode-git's pkgbuild is more up to date. https://aur.archlinux.org/packages/lolcode-git/ https://aur.archlinux.org/packages/lci-git/ J. Leclanche
Re: [aur-general] TU application
On 20 July 2013 21:21, Dicebot wrote: > It is nothing of real importance but question is, what harm does > explicit versioning do? It has no direct or immediate harmful consequence, but it is a packaging convention here. Most of our uses for versioning dependencies come during testing (when the package along with its dependencies is in that repo) and rebuilds (when a whole bunch of packages are moved wholesale with their proper dependencies). Otherwise, you may find core packages to have these things in order to be compatible (or rather, not be compatible) with certain other things. We simply do not care about legacy upstream dependency information because we provide the latest, always. If you have a strong reason (and not just copying verbatim upstream's minimum requirements), go ahead and keep things versioned. -- GPG/PGP ID: C0711BF1
Re: [aur-general] TU application
On 20/07/13 12:40 PM, Karol Blazewicz wrote: > On Sat, Jul 20, 2013 at 9:32 PM, Connor Behan > wrote: >> On 20/07/13 09:53 AM, Sébastien Luttringer wrote: >>> 4) Speed >>> It avoid pacman to checks version for each deps. This save a lot of >>> useless computing (parsing and comparing two version)[1]. >>> Even if it's not a big deal on last intel processor, this is >>> noticeable on slow processor (like raspberry pie, alix or soekris). >>> >>> We can resume these 4 points by saying : It's more simple. >>> >>> Of course there is drawback for people not updating the whole system. >>> It's unsupported. >>> >> Those processors are no more supported than partial updates. > pacman doesn't have Arch Linux-specific stuff but other distros / > systems should be running on powerful processors because pacman devs > don't care about slower ones? For some of the other distro's PKGBUILDs, it may very well be advisable to omit ">, <, >=, <=, =". I just don't think this can be used to argue that the i686 and x86_64 PKGBUILDs in Arch should as well. signature.asc Description: OpenPGP digital signature
Re: [aur-general] TU application
On Sat, Jul 20, 2013 at 9:32 PM, Connor Behan wrote: > On 20/07/13 09:53 AM, Sébastien Luttringer wrote: >> 4) Speed >> It avoid pacman to checks version for each deps. This save a lot of >> useless computing (parsing and comparing two version)[1]. >> Even if it's not a big deal on last intel processor, this is >> noticeable on slow processor (like raspberry pie, alix or soekris). >> >> We can resume these 4 points by saying : It's more simple. >> >> Of course there is drawback for people not updating the whole system. >> It's unsupported. >> > Those processors are no more supported than partial updates. pacman doesn't have Arch Linux-specific stuff but other distros / systems should be running on powerful processors because pacman devs don't care about slower ones?
Re: [aur-general] TU application
On 20/07/13 09:53 AM, Sébastien Luttringer wrote: > On Sat, Jul 20, 2013 at 3:21 PM, Dicebot wrote: >> It is nothing of real importance but question is, what harm does >> explicit versioning do? > Interesting question because it underlines some benefits of being a > rolling release for their maintainers. > > 1) Productivity > You don't need to modify your package deps each time you update it. > You only have to check (most of time, read the changelog). > When upstream check this for you, in a configure or by providing a > test suite, you could even forget the minimal version check and free > your mind to do interesting things. > Arch maintainers manage a high number of packages, every unnecessary > update is time lost. > > 2) Correctness > More than avoid unnecessary changes in the update process, it avoid > mistakes (and their fixes). > When upstream doesn't provides minimal deps, it's long (and not easy) > to find which minimal version is really required. > > 3) Troublemaker > The version is about a package, *NOT* an upstream source. > > I remember a discussion with a Debian developer about opening a bugfix > because the required dep version is badly too high. > A maintainer, wants a lib compiled with an option (e.g. --with-caca), > so he bumps the lib version (e.g. from 1.15-1 to 1.15-2) and require > it in his package (e.g: from 1.10-1 to 1.15-2). > The old versions (from 1.10 to 1.15 in the previous example) of the > library is working perfectly (if you rebuild the package with the > option --with-caca). > Its happens (sometimes) when you do a backport on Debian. > > You don't know, by looking at it, if a required version is due to > upstream or downstream change. These are good reasons why a package maintainer should not obsess over finding the minimum required versions for everything. But if you already happen to know what they are, users who recompile packages or do other customization would appreciate this information. > 4) Speed > It avoid pacman to checks version for each deps. This save a lot of > useless computing (parsing and comparing two version)[1]. > Even if it's not a big deal on last intel processor, this is > noticeable on slow processor (like raspberry pie, alix or soekris). > > We can resume these 4 points by saying : It's more simple. > > Of course there is drawback for people not updating the whole system. > It's unsupported. > Those processors are no more supported than partial updates. signature.asc Description: OpenPGP digital signature
[aur-general] request merge/delete vapoursynth-svn to vapoursynth-git
please merge/delete: https://aur.archlinux.org/packages/vapoursynth-svn/ into https://aur.archlinux.org/packages/vapoursynth-git/ sources move from svn to git greetings
Re: [aur-general] TU application
On Sat, Jul 20, 2013 at 3:21 PM, Dicebot wrote: > It is nothing of real importance but question is, what harm does > explicit versioning do? Interesting question because it underlines some benefits of being a rolling release for their maintainers. 1) Productivity You don't need to modify your package deps each time you update it. You only have to check (most of time, read the changelog). When upstream check this for you, in a configure or by providing a test suite, you could even forget the minimal version check and free your mind to do interesting things. Arch maintainers manage a high number of packages, every unnecessary update is time lost. 2) Correctness More than avoid unnecessary changes in the update process, it avoid mistakes (and their fixes). When upstream doesn't provides minimal deps, it's long (and not easy) to find which minimal version is really required. 3) Troublemaker The version is about a package, *NOT* an upstream source. I remember a discussion with a Debian developer about opening a bugfix because the required dep version is badly too high. A maintainer, wants a lib compiled with an option (e.g. --with-caca), so he bumps the lib version (e.g. from 1.15-1 to 1.15-2) and require it in his package (e.g: from 1.10-1 to 1.15-2). The old versions (from 1.10 to 1.15 in the previous example) of the library is working perfectly (if you rebuild the package with the option --with-caca). Its happens (sometimes) when you do a backport on Debian. You don't know, by looking at it, if a required version is due to upstream or downstream change. 4) Speed It avoid pacman to checks version for each deps. This save a lot of useless computing (parsing and comparing two version)[1]. Even if it's not a big deal on last intel processor, this is noticeable on slow processor (like raspberry pie, alix or soekris). We can resume these 4 points by saying : It's more simple. Of course there is drawback for people not updating the whole system. It's unsupported. Cheers, [1] https://projects.archlinux.org/pacman.git/tree/lib/libalpm/version.c#n232 -- Sébastien "Seblu" Luttringer https://www.seblu.net GPG: 0x2072D77A
Re: [aur-general] TU application
On 15.07.2013 22:31, Dicebot wrote: > [sponsor : Sven-Hendrik Haase] > [AUR account : https://aur.archlinux.org/account/Dicebot] > [IRC : Dicebot @ irc.freenode.net] > > Hello, > > Long story short - I am insterested in becoming a Trusted User and > taking care of packages related to D programming language. > > I have been using Arch Linux for last ~5 years but that does not really > matter as I have never spent any considerable time maintaining packages. > What does matter though is that I am quite active member of D community > and familiar with minor details about its current infrastructure and > have personal interest in improving user experience in that domain. > > I have been maintaing reference D compiler package (dmd2) in AUR > before its inclusion into main repositories and kept contacting > Sven-Hendrik with various improvement proposals after. At some point > in the relatively long mail thread he has suggested to make a TU > application so that I can take over those packages and maintain them > directly - which is the primary motivating reason behind this mail. > > As my general competence level as a packager relatively low I am > planning to solely focus on domain I am proficient with - D compilers, > libraries and notable applications. Also contacting with D maintainers > in other distros to ensure reasonable consistency. > > Regards, > > Dicebot Discussion period has ended. Start the voting: https://aur.archlinux.org/tu/?id=69 signature.asc Description: OpenPGP digital signature
Re: [aur-general] TU application
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 7/20/2013 12:26 AM, Sébastien Luttringer wrote: > Almost all packages may have versioned dependencies, and we don't > do that. It's not because we don't know the minimum required > version. As we are a rolling release, we know that the system must > be upgraded completly. So you need to check the current version in > repositories (and update it if it's not enough). In this case, dmd > is in version 2.063.2 in a stable and official repository, why do > you need a versioned deps specifically? I doubt anyone really "needs" them but I have found it to be a nice self-documenting feature so far, matter of minor convenience. Until very recently dmd releases has plenty of breaking changes and practical D users usually waited some time before updating to fresh release until those issues are taken care of. In that sense differentiating between programs that work only on latest release and ones that work on at least last two can be pretty useful. Guess that is only applicable to AUR stuff. It is nothing of real importance but question is, what harm does explicit versioning do? -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.21-beta20 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJR6o7eAAoJEHYfrWm6BsapjkQH/iuMPffBPsSZCA9RQVygCVV6 m1qtJgBxguVlnAnE7relps0r3BPyhd8RCSuW9pRBNdDmN673WG4KT0U3jI1GXSYR NKnClRKMZeFq3t+vwARX8Sm5H0Yk6Hir3zTF5PGJfAiNJmqYW5+xAUf3GrxKWNIJ jaEsCxM5vOfGR1JxPo9ZgFxDPE4oa5tTlmVbwulVkahTdqXueH52syc4crDKs5qU YfzY3G2roUOiqwfHSXdi+pon3MaTL+KxV1At0A6yTTmcoTqZEF3ZxOi/IvqOBTpM hhoOuL8hjapQe+v8FODRWv3fm7giOg7cO+HTP+BJoDLYbPntG3RiFf8qS3V4BYE= =6lLS -END PGP SIGNATURE-
Re: [aur-general] About orphaning all packages of inactive users
On 07/20/2013 01:58 PM, Karol Blazewicz wrote: On Sat, Jul 20, 2013 at 1:44 PM, Willem wrote: What about the package users? Will users who have voted for a package be emailed that the package is about to be deleted (automatically)? And be asked whether he wants to become the maintainer? I'm confused. Are we talking about orphaning or deleting packages? Even if there's no comment left about the package being orphaned, you can periodically run e.g. aurphan to check. There's also https://bugs.archlinux.org/task/31851 Thanks for the tip. Sorry, yes you're right. The fifth message of this thread hints at deleting packages, however that's not the scope of this thread.
Re: [aur-general] About orphaning all packages of inactive users
On Sat, Jul 20, 2013 at 1:44 PM, Willem wrote: > What about the package users? > > Will users who have voted for a package be emailed that the package is about > to be deleted (automatically)? And be asked whether he wants to become the > maintainer? I'm confused. Are we talking about orphaning or deleting packages? Even if there's no comment left about the package being orphaned, you can periodically run e.g. aurphan to check. There's also https://bugs.archlinux.org/task/31851
Re: [aur-general] About orphaning all packages of inactive users
What about the package users? Will users who have voted for a package be emailed that the package is about to be deleted (automatically)? And be asked whether he wants to become the maintainer?
Re: [aur-general] Orphan request: chm2pdf
On Sat 20 Jul 2013 at 09:22, Mariusz Libera wrote: > Hi, > please orphan chm2pdf, PKGBUILD is broken, maintainer didn't respond to > comment nor mail I sent on 5 of July. > > https://aur.archlinux.org/packages/chm2pdf/ > > Mariusz Libera All yours. -- Jonathan Steel pgp6rAOM0Xd16.pgp Description: PGP signature
[aur-general] Signoff report for [community-testing]
=== 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 * 14 packages missing signoffs * 12 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) == * uwsgi-1.9.13-2 (i686) * uwsgi-1.9.13-2 (x86_64) == Incomplete signoffs for [community] (12 total) == * bbswitch-0.7-5 (i686) 0/1 signoffs * r8168-8.036.00-2 (i686) 0/1 signoffs * rt3562sta-2.4.1.1-35 (i686) 0/1 signoffs * tp_smapi-0.41-26 (i686) 0/1 signoffs * vhba-module-20130607-5 (i686) 0/1 signoffs * virtualbox-modules-4.2.16-2 (i686) 0/1 signoffs * bbswitch-0.7-5 (x86_64) 0/2 signoffs * r8168-8.036.00-2 (x86_64) 0/2 signoffs * rt3562sta-2.4.1.1-35 (x86_64) 0/2 signoffs * tp_smapi-0.41-26 (x86_64) 0/2 signoffs * vhba-module-20130607-5 (x86_64) 0/2 signoffs * virtualbox-modules-4.2.16-2 (x86_64) 0/2 signoffs == Incomplete signoffs for [unknown] (2 total) == * uwsgi-1.9.13-2 (i686) 0/1 signoffs * uwsgi-1.9.13-2 (x86_64) 0/2 signoffs == All packages in [community-testing] for more than 14 days (12 total) == * vhba-module-20130607-5 (i686), since 2013-07-05 * vhba-module-20130607-5 (x86_64), since 2013-07-05 * r8168-8.036.00-2 (i686), since 2013-07-05 * r8168-8.036.00-2 (x86_64), since 2013-07-05 * rt3562sta-2.4.1.1-35 (i686), since 2013-07-05 * rt3562sta-2.4.1.1-35 (x86_64), since 2013-07-05 * bbswitch-0.7-5 (i686), since 2013-07-05 * bbswitch-0.7-5 (x86_64), since 2013-07-05 * tp_smapi-0.41-26 (i686), since 2013-07-05 * tp_smapi-0.41-26 (x86_64), since 2013-07-05 * virtualbox-modules-4.2.16-2 (i686), since 2013-07-05 * virtualbox-modules-4.2.16-2 (x86_64), since 2013-07-05 == Top five in signoffs in last 24 hours == 1. eric - 3 signoffs
Re: [aur-general] About orphaning all packages of inactive users
On Sat 20 Jul 2013 at 07:49, Frederik "Freso" S. Olesen wrote: > Den 19-07-2013 22:45, Jonathan Steel skrev: > >[...] If in doubt, an email to > >them won't hurt, but in my experience this has always lead to disowning them. > > FWIW, I've sent e-mails to maintainers that replied back and got > around to updating their packages. You likely don't hear about > these, as the requests (seldomly, anyway) come to this mailing list. > It's true that I have more often not gotten a reply, but it does > happen that I have. We are talking about users who have been inactive for a more than a year, especially ones that have ignored flags/comments for a long time; have users really come back after a year or so just because you emailed them? -- Jonathan Steel pgpKPbnwovsVa.pgp Description: PGP signature
[aur-general] Orphan request: chm2pdf
Hi, please orphan chm2pdf, PKGBUILD is broken, maintainer didn't respond to comment nor mail I sent on 5 of July. https://aur.archlinux.org/packages/chm2pdf/ Mariusz Libera
