Re: [aur-general] TU Application: David Runge
On 18 October 2017 at 18:40, Rashif Ray Rahman wrote: > The discussion begins now and will last until 23 October, after which > the voting period will begin on 24 October. Good luck David! The formal discussion period is over, please cast your votes! The voting period will last until 31 October. I do have one thing to say to David: please do think about the time commitment associated with this. If you think that you won't be able to commit much starting out, then it will be quite sad moving forward. Otherwise, I say again that David's proposal has followed standard procedure, including a holistic review by myself the sponsor. Some issues were raised based on automated tool reports, which I think David will be able to resolve. Good luck! -- GPG/PGP ID: C0711BF1
Re: [aur-general] TU Application: David Runge
On 24 October 2017 at 11:50, Levente Polyak wrote: > At this point my feedback goes to the sponsor instead of the applicant: > > Sorry, but I must say that I really dislike sponsoring a TU applicant without > looking at any PKGBUILD and give some advice. In my world this is part of the > sponsorship and one of the jobs of a "TU mentor". I understand that you could > certainly make some judgment based on the contributions you mentioned, but > still. > > I hope this will not become a trend, otherwise we could also just get rid of > the whole sponsorship (which we shouldn't). Err, I never wrote that I did not check his packages. I only wrote I did not check his packages "thoroughly". Perhaps I should have been so honest, but thanks for raising your concern. What are you referring to as a "trend"? A TU sponsor usually just confirms a sponsorship. The assumption is that before sending in the proposal, the sponsor has already done the pre-requisite review and screening. I am not going to be pedantic about many things which are fixable (I couldn't care less about them myself). I am satisfied with what I have seen and leave the rest up to the community. The by-laws prescribe a discussion period for exactly this aspect of peer review. If perhaps you (or anyone else) thought I simply picked him at random, then that is a misunderstanding. There were several other candidates, and I had to spend the time to calculate several metrics to decide on one. That includes checking _some_ packages -- it's called sampling. -- GPG/PGP ID: C0711BF1
Re: [aur-general] TU Application: David Runge
On 18 October 2017 at 05:07, David Runge wrote: > Hi all, > > my name is David Runge. You may have come across me somewhere on the > wiki [1], the forums [2] (not so recently), the AUR [3] or the mailing > lists (mainly arch-general). I'm sponsored by Ray Rashif. I confirm my sponsorship. I have to be honest that I have not checked David's PKGBUILDs thoroughly, but he has been in contact with me with contributions. He has the skill set necessary to both maintain packages and debug software, as well as test them correctly. If his application is successful, he will be co-maintainer for all my and Spep's packages in [community]. The discussion begins now and will last until 23 October, after which the voting period will begin on 24 October. Good luck David! -- GPG/PGP ID: C0711BF1
Re: [aur-general] Doubts about Java {,bindings} packages
On 15 July 2015 at 18:27, Giovanni Santini wrote:
> The actual packages I'm referring to are opencv[1] and gettext[2], for
> which I've created {opencv,gettext}-java (see [3],[4]).
For opencv, it has been an idle TODO for a very long while because of
my downtime. [1] Now that opencv 3.x is out, I will attend to this
again. It is really trivial, so you can do it yourself for the time
being (and upload to AUR if you like) if you really need it.
[1] https://bugs.archlinux.org/task/41452
--
GPG/PGP ID: C0711BF1
Re: [aur-general] Upstream for jrosetta package gone down.
On 13 May 2015 at 00:44, Victor Dmitriyev wrote: > Offtopic question, is there any information online about ftp.archlinux.org > or sources.archlinux.org? If you're referring to hosting upstream sources, the former was used by our packagers only, and as a last resort (it was throttled). The latter now hosts those sources in the "other" directory, and the "sources" directory hosts automated full source packages required for GPL compliance. -- GPG/PGP ID: C0711BF1
Re: [aur-general] [arch-general] warning: foobar: local (1.0.0-2) is newer than community (1.0.0-1)
On 17 January 2015 at 18:23, Jan Alexander Steffens wrote: > Resetting the pkgrel is indeed wrong. pkgrel should be bumped when > moving to [community], and that has been my habit when moving packages > from the AUR. I agree. Even I used to be guilty. Although this is not AFAIK documented anywhere, we were recommended to do this whenever the question came up. I have added this as an AUR guideline: https://wiki.archlinux.org/index.php?title=AUR_Trusted_User_Guidelines&diff=356844&oldid=356556 -- GPG/PGP ID: C0711BF1
Re: [aur-general] Rules about providing "compiled" documentation
On 6 January 2015 at 17:01, JoKoT3 wrote: > Also note that generating the info file is not a default target of the > Makefile since version 4.6.4. Then forget about it (2), unless requested by other users. What upstream does not provide, don't go out of your way to do it yourself. If users do request it, inform upstream and do it in your package (1). It is then OK if upstream does not heed your request. You can continue to provide it via method (1) as long as it has no adverse effects on functionality and/or upstream support. -- GPG/PGP ID: C0711BF1
Re: [aur-general] What stops more packages moving from AUR to Community?
On 26 May 2014 15:19, Steven Honeyman wrote: > Either way, perhaps the Wiki should be changed to say 1000 votes instead :D Popularity is not the only criterion involved. A package may have deficiencies elsewhere that are preventing it from being supported in [community]. For example, it may not be freely re-distributable. -- GPG/PGP ID: C0711BF1
Re: [aur-general] Delete request: fluidr3
On 27 February 2014 21:30, Maxime Gauduin wrote: > On Thu, Feb 27, 2014 at 4:07 PM, Rashif Ray Rahman wrote: > >> On 23 February 2014 05:02, Maxime Gauduin wrote: >> > On Sat, Feb 22, 2014 at 10:16 PM, Jerome Leclanche > >wrote: >> > >> >> https://aur.archlinux.org/packages/fluidr3/ >> >> >> >> Appears to be the same packaged data as >> >> https://aur.archlinux.org/packages/soundfont-fluid/ except it doesn't >> >> build properly. Note: I might be wrong on this, but I can't figure out >> >> how to make it build. >> >> >> >> J. Leclanche >> >> >> > >> > I haven't tried building the fluidr3 package recently, but that sfark >> > format is a pain in the neck anyway. The fluidr3 soundfont from >> > soundfont-fluid doesn't use that and comes with changes from the >> musescore >> > guys, so it's actucally a more up-to-date version of the original fluidr3 >> > by hammersound. I'll merge fluidr3 into soundfont-fluid. Thx. >> >> Sfark decompression became a non-issue early last year. [1][2] The >> upstream author made contact, and sfarkxtc is maintained by a known >> (at least to me) member of the Linux audio community. [3] >> >> A sfark-compressed soundfont is still helpful for people with slow >> Internet connections; 72 MB from 124 MB is a 42%, 52 MB reduction! >> That's an extra 13 minutes and a dollar (or even more) for some. >> >> Fair enough. > > >> In conclusion, soundfont-fluid is a better package name, but the >> original fluidr3 that existed in the AUR and depended on a >> decompressor is (since Feb 2013) not obsoleted by musescore's changes >> -- unless they're actually critical to be worth the extra megs. >> >> Here is the changelog from MuseScore (BlissSam: which BTW is shipped in > the archive, along with the original ReadMe from Hammersound): > > "Missing note (#94) added to Violin and range extended to G7 (MIDI#103) for > compatibility with MuseScore 2" > > Anyone not using the Violin font or MuseScore may argue that the changes > aren't critical enough. > > >> >> [1] http://melodymachine.com/sfark-linux-mac >> [2] >> http://www.linuxmusicians.com/viewtopic.php?f=24&t=9854&start=15#p35712 >> [3] https://github.com/raboof/sfarkxtc >> >> -- >> GPG/PGP ID: C0711BF1 >> > > I'd rather stick with the version from MuseScore, but yeah, bandwitdth is > not a problem here and as you pointed out, I understand if people would > like to have separate packages. How about soundfont-fluid for the original > soundfont from hammersound and soundfont-fluid-musescore for the modified > soundfont? No, don't bother with that. I simply wanted to point out that someone could continue maintaining the sfark-compressed version without fearing deletion (whatever name it has/will have). Most distributions use the musescore source, and the change is significant enough, so there's no further issue there. -- GPG/PGP ID: C0711BF1
Re: [aur-general] Delete request: fluidr3
On 23 February 2014 05:02, Maxime Gauduin wrote: > On Sat, Feb 22, 2014 at 10:16 PM, Jerome Leclanche wrote: > >> https://aur.archlinux.org/packages/fluidr3/ >> >> Appears to be the same packaged data as >> https://aur.archlinux.org/packages/soundfont-fluid/ except it doesn't >> build properly. Note: I might be wrong on this, but I can't figure out >> how to make it build. >> >> J. Leclanche >> > > I haven't tried building the fluidr3 package recently, but that sfark > format is a pain in the neck anyway. The fluidr3 soundfont from > soundfont-fluid doesn't use that and comes with changes from the musescore > guys, so it's actucally a more up-to-date version of the original fluidr3 > by hammersound. I'll merge fluidr3 into soundfont-fluid. Thx. Sfark decompression became a non-issue early last year. [1][2] The upstream author made contact, and sfarkxtc is maintained by a known (at least to me) member of the Linux audio community. [3] A sfark-compressed soundfont is still helpful for people with slow Internet connections; 72 MB from 124 MB is a 42%, 52 MB reduction! That's an extra 13 minutes and a dollar (or even more) for some. In conclusion, soundfont-fluid is a better package name, but the original fluidr3 that existed in the AUR and depended on a decompressor is (since Feb 2013) not obsoleted by musescore's changes -- unless they're actually critical to be worth the extra megs. [1] http://melodymachine.com/sfark-linux-mac [2] http://www.linuxmusicians.com/viewtopic.php?f=24&t=9854&start=15#p35712 [3] https://github.com/raboof/sfarkxtc -- GPG/PGP ID: C0711BF1
Re: [aur-general] TU application sponsored by David Reisner
On 5 February 2014 12:57, Anatol Pomozov wrote: > I still need to understand why Arch community is split into two groups > 'developers' and 'trusted users'. They seems have similar > responsibilities: maintaining packages and developing Arch toolset. For historical reasons: https://wiki.archlinux.org/index.php/Community_repository#History The [community] repository began as a binary repository for the AUR. It still retains that function, but the split is no longer as pronounced. Basically, slightly popular packages go into [community], and very popular ones into [extra]. The [extra] repo has a tighter control over what goes in, whereas [community] is almost open. Both groups have useful people: the pacman, core and early userspace folks, and the AUR back-end folks. -- GPG/PGP ID: C0711BF1
Re: [aur-general] TU application sponsored by David Reisner
On 4 February 2014 03:26, Anatol Pomozov wrote: > - add android-sdk-* packages. Current AUR packages download binaries > and install binaries to /opt/bin. The binaries are 32-bit. Instead we > should build SDK from sources and provide proper 64/32-bit binaries. > This might be tricky as Android build system is complicated. You have my full support. Several of us are just waiting to be spoon-fed with this. I downloaded 8GB worth of sources on a remote machine, trimmed and tarred it to 1GB, just to build a custom recovery for a cheapo device. -- GPG/PGP ID: C0711BF1
Re: [aur-general] TU application, sponsored by Lukas Fleischer
On 25 January 2014 02:53, carstene1ns wrote: > closing words: > I know this reads in parts like a rant, but it is just to show you that > also current TUs are not better in some aspects. > Again it is not meant to blame speps (but seriously, just orphan some > packages! :P) or Dragonlord. Just my two cents. If you're saying that neither these TUs nor the applicant are doing too many things wrong, then I have to agree with you. Personally, I'm not a fan of cherry-picking bad habits when there are enough good things to talk about, but questions should be raised to clarify certain practices. So, you bring up a good point there, but I'm sure all three of them can explain. -- GPG/PGP ID: C0711BF1
Re: [aur-general] Can we force the maintainer to change package name?
On 12 January 2014 23:42, Karol Blazewicz wrote: > On Fri, Dec 20, 2013 at 3:41 PM, Karol Blazewicz > wrote: >> On Fri, Dec 20, 2013 at 3:19 PM, Lukas Jirkovsky >> wrote: >>> On Fri, Dec 20, 2013 at 2:24 PM, Rashif Ray Rahman >>> wrote: >>>> Since there was no 'rstudio' at the time that user uploaded this one, >>>> there is no infringement of any rule or guideline per se. Just tell >>>> them to upload an 'r-studio' to mitigate the confusion that resulted >>>> from it. I don't think there is any need to merge unless there were >>>> relevant comments. It is up to the maintainer to update the PKGBUILD >>>> with the suggested changes. >>> >>> The question is whether the maintainer is still active at all. Hist >>> last action is 2012-08-27 and he has only two packages, both over the >>> year old with one being flagged out of date since February. >>> >>> Lukas >> >> e-mail sent. >> If he doesn't respond in two weeks, maybe a TU can reupload and disown >> it, or remove it from the AUR altogether, whichever is deemed the >> correct action. > > The maintainer has taken no action and didn't respond to my e-mail. Did your e-mail actually get through to that address? It's being returned here, and if we'd known this before we could've just gone ahead and done what we wanted. An non-existent e-mail address is close to meaning a non-existent user. -- GPG/PGP ID: C0711BF1
Re: [aur-general] Can we force the maintainer to change package name?
On 12 January 2014 23:42, Karol Blazewicz wrote: > On Fri, Dec 20, 2013 at 3:41 PM, Karol Blazewicz > wrote: >> On Fri, Dec 20, 2013 at 3:19 PM, Lukas Jirkovsky >> wrote: >>> On Fri, Dec 20, 2013 at 2:24 PM, Rashif Ray Rahman >>> wrote: >>>> Since there was no 'rstudio' at the time that user uploaded this one, >>>> there is no infringement of any rule or guideline per se. Just tell >>>> them to upload an 'r-studio' to mitigate the confusion that resulted >>>> from it. I don't think there is any need to merge unless there were >>>> relevant comments. It is up to the maintainer to update the PKGBUILD >>>> with the suggested changes. >>> >>> The question is whether the maintainer is still active at all. Hist >>> last action is 2012-08-27 and he has only two packages, both over the >>> year old with one being flagged out of date since February. >>> >>> Lukas >> >> e-mail sent. >> If he doesn't respond in two weeks, maybe a TU can reupload and disown >> it, or remove it from the AUR altogether, whichever is deemed the >> correct action. > > The maintainer has taken no action and didn't respond to my e-mail. Deleted the package. I have it backed up, will keep for several weeks in case someone really wants it reuploaded. -- GPG/PGP ID: C0711BF1
Re: [aur-general] pkgbuild.com
On 10 January 2014 10:28, Iru Cai wrote: > 2014/1/10 Zuyi Hu > > > Who know how to get an account on pkgbuild.com?Thanks a lot! > > > I think only TUs and developers can get an account. > Yes, it is just to lend official packagers some processing and bandwidth power if they'd rather not use their own machines. -- GPG/PGP ID: C0711BF1
Re: [aur-general] Bundled applications policy?
On 20 December 2013 04:20, WorMzy Tykashi wrote: > On 19 December 2013 18:44, Rashif Ray Rahman wrote: >> Just provide for and conflict with the relevant packages and you don't >> give anyone any trouble. > > It's halfway there, it doesn't conflict with or provide theharvester > package, though that's something I was going to mention when I comment > about some changes they should make to the PKGBUILD (shouldn't be an > 'any' package, binaries shouldn't be in /usr/sbin, etc.). I just > wanted to check that such packages are allowed before prompting them > to fix it up. > >> But if this whole thing is a package of a real >> software collection (and not just a mash-up by a packager) then I see >> no problem. > > It's the latter, the package pulls from two different, unrelated > sources and merges them into one package. The only thing is, neither > source is otherwise available on the AUR or official repositories (as > far as I can tell). A better way to rephrase what I meant is this: if it's a useful bundle that people will use (if some people find the beta dep better), then there is no problem. The "Arch way" would be to provide a separate package for the beta dep instead, but you can tell if your idea (of bundling) is working if nobody says anything about that. -- GPG/PGP ID: C0711BF1
Re: [aur-general] Can we force the maintainer to change package name?
On 20 December 2013 06:42, Karol Blazewicz wrote: > On Thu, Dec 19, 2013 at 7:35 PM, Rashif Ray Rahman > wrote: >> On 20 December 2013 01:11, Karol Blazewicz wrote: >>> https://aur.archlinux.org/packages/rstudio/ is something entirely >>> different than every other 'rstudio' package >>> https://aur.archlinux.org/packages/?&K=rstudio >>> A few users suggested name change. >> >> I was fooled for a second. I thought this was just another R Studio. > > I'm guilty of not reading the package description too: > https://bbs.archlinux.org/viewtopic.php?pid=1361971#p1361971 > > >>> Can we force the maintainer to change package name? Does the package >>> have to be properly disowned and reuploaded with a different name? >> >> Yeah, they have to conform to existing naming schemes. I say rename it >> to r-studio, though that doesn't really look that much more helpful. > > I can e-mail the maintainer and we can wait the customary 2 weeks, but > what exactly should I tell him? > He did provide a description, so maybe uploading an r-studio package > using the PKGBUILD provided by gbc921 would be enough? Since there was no 'rstudio' at the time that user uploaded this one, there is no infringement of any rule or guideline per se. Just tell them to upload an 'r-studio' to mitigate the confusion that resulted from it. I don't think there is any need to merge unless there were relevant comments. It is up to the maintainer to update the PKGBUILD with the suggested changes. -- GPG/PGP ID: C0711BF1
Re: [aur-general] Bundled applications policy?
On 20 December 2013 01:36, WorMzy Tykashi wrote: > Hi, > > What is the policy regarding collection/amalgamation packages? > 'manarchy' [1] is just a recent beta version of aircrack-ng (stable > version in community) and an updated version of 'theharvester' [2] > bundled together. > > Should [1] be removed/merged into [2], or should it split up into > individual packages, or is it perfectly acceptable to have packages > like this? Just provide for and conflict with the relevant packages and you don't give anyone any trouble. Alternatively, you could package up the beta version of the dep. But if this whole thing is a package of a real software collection (and not just a mash-up by a packager) then I see no problem. -- GPG/PGP ID: C0711BF1
Re: [aur-general] Can we force the maintainer to change package name?
On 20 December 2013 01:11, Karol Blazewicz wrote: > https://aur.archlinux.org/packages/rstudio/ is something entirely > different than every other 'rstudio' package > https://aur.archlinux.org/packages/?&K=rstudio > A few users suggested name change. I was fooled for a second. I thought this was just another R Studio. > Can we force the maintainer to change package name? Does the package > have to be properly disowned and reuploaded with a different name? Yeah, they have to conform to existing naming schemes. I say rename it to r-studio, though that doesn't really look that much more helpful. -- GPG/PGP ID: C0711BF1
Re: [aur-general] Possible to switch the votes/comments for two packages?
On 8 December 2013 21:07, member graysky wrote: > On Sunday, December 8, 2013, Rashif Ray Rahman wrote: >> >> >> 1. Backup mprime >> 2. Merge mprime into mprime-bin >> 3. Delete non-relevant comments from mprime-bin >> 4. Reupload mprime from backup >> >> This should work to retain mprime-bin's data, but I'm not intricately >> familiar with the process. Unfortunately, you can't remove >> non-relevant votes (but you can tell others to remove theirs). >> > > I have both backed-up here. Can you or another TU implement this 4 step > plan? Sorry, this got lost. I thought Felix was already helping you. Anyway, merged. You can now take over from (3). -- GPG/PGP ID: C0711BF1
Re: [aur-general] Possible to switch the votes/comments for two packages?
On 8 December 2013 19:17, member graysky wrote: > On Sat, Dec 7, 2013 at 9:27 PM, Felix Yan wrote: >> >> Just had a look, but now 'mprime' also has comments for itself. So I'd >> suggest to merge mprime-bin (with its votes/comments) to mprime, then you >> just re-upload the mprime-bin package. Please let me know if this is ok so I >> proceed, or maybe a better approach? :D >> > > Hi Felix. If you do that, and I then reup mprime-bin, won't that mean > all the votes will be with the mprime package? That is not a > reflection of reality. The votes/comments should stay with the > mprime-bin package. What do you think? Your mistake was to update the mprime package before requesting a merge. You were probably not aware of the merge functionality that TUs have access to. The merge is one way -- meaning, you can't copy and retain data for reuse more than once. Now, your original package has new comments that are only relevant since the update. Your mprime-bin is a loner at this point. Barring intervention from an AUR developer, you have to sacrifice data of either one of the packages. For -bin: 1. Backup mprime 2. Merge mprime into mprime-bin 3. Delete non-relevant comments from mprime-bin 4. Reupload mprime from backup This should work to retain mprime-bin's data, but I'm not intricately familiar with the process. Unfortunately, you can't remove non-relevant votes (but you can tell others to remove theirs).
Re: [aur-general] Changes in Arch packaging standards
On 6 December 2013 17:25, Sergej Pupykin wrote: > Bartłomiej Piotrowski proposed packaging standard changes: Where is this proposal? I think he simply meant that it is the current practice. > if there are 2 versions of some package foobar, then older version (1.0 > for example) must be named as foobar1-1.0 and newer version (2.0 for > example) must be named as foobar-2.0. That's the standard case, yes, since we strive to keep in line with upstream. If upstream says "the latest release of FOO" and not "the latest release of FOO2", we simply retain the name and relegate the older version to a suffixed package. > I did not see such rule yet on > https://wiki.archlinux.org/index.php/Arch_Packaging_Standards#Package_naming It's not a documented rule, but you have seen this with Python. > but my package openjpeg2 was silently removed with this reason That is simply wrong. We are not known to do this, no matter how inactive someone else is. A notification is always the right way. > I insist on giving me proof-link for this rule, including this rule > into wiki > (https://wiki.archlinux.org/index.php/Arch_Packaging_Standards#Package_naming) > and renaming all packages according this rule. Sven's proposal should get that rolling. -- GPG/PGP ID: C0711BF1
Re: [aur-general] removal request for rt-tests-git
On 2 December 2013 00:31, Joakim Hernberg wrote: > rt-tests-git is no longer needed as when there are changes a new > tarball is published and covered by the rt-tests buildscript. It was > only created when kernel.org had been hacked and there was a problem > getting the tarballs. > > No need to merge into rt-tests. > > Thanks in advance, Gone :) -- GPG/PGP ID: C0711BF1
Re: [aur-general] question about git package as a dependency
On 28 November 2013 02:27, Lieven Moors wrote: > With devel functionality, do you mean header files? Wouldn't they > be needed to build non-daw-git anyway? I meant experimental functionality (i.e. development branch). > The problem is that ntk-git has been in a state of constant flux, > and non-daw-git would often refuse to build, unless you rebuild > ntk-git first... Then you should just depend on ntk (but doesn't make a difference if a git development source is all there is). -- GPG/PGP ID: C0711BF1
Re: [aur-general] question about git package as a dependency
On 27 November 2013 04:43, Lieven Moors wrote: > I think technically, ntk-git should provide > ntk, and non-daw-git should depend on some git-release > of ntk. You can depend on ntk-git, but a better approach is to have ntk-git provide ntk, and depend on that -- if devel functionality of ntk is not required by non-daw-git. So just nudge the ntk-git maintainer. -- GPG/PGP ID: C0711BF1
Re: [aur-general] Backslash to split lines in `depends` array
On 3 November 2013 20:29, Fabien Dubosson wrote: > The problem doesn't seem to appear with `yaourt` [3] . So before filling a > bug request to `aura`, I wanted to be sure that it is allowed/common to use > `\` to split lines in the `depends` array? For an even more simplistic understanding: foo=(one \ two) is understood as: foo=(one two) as much as: foo=(one two) PKGBUILDs are simply Bash scripts, so it's not about what is allowed in the 'depends' array, but what is valid Bash. The '\' is redundant but valid. The wrapper you're using is simply not doing a perfect job of parsing Bash, but it's not that big of a deal. Also note that use of single quotes protects interpretable characters (try versioned depends without quotes), while double quotes allow variable expansion. Using either type of quoting throughout an array is a stylistic choice. At the end of the day, the lesson learnt here is to use supported tools, or at least an unsupported one that has stood the test of time (if you don't want to bother troubleshooting functional glitches). -- GPG/PGP ID: C0711BF1
Re: [aur-general] Merge request: projectm-jack
On 3 November 2013 16:18, Allen Li wrote: > On Sun, Nov 03, 2013 at 03:21:54PM +0800, Rashif Ray Rahman wrote: >> On 3 November 2013 12:02, Allen Li wrote: >> > It is possible to merge projectm-jack in the AUR with the one in >> > community? I am the maintainer for the package in the AUR, and there's >> > no need for it anymore since it is in community. >> > >> > Allen >> >> File a feature request at our bugtracker. > > Sorry, for some reason this seemed ambiguous to me. Do you mean file a > request for the merge, or file a request for the feature to be able to > merge AUR packages into repo packages? I thought the former, but I'm > not sure now... My bad, I assumed only projectm was in the repos, and the -jack version was not. In this case, the AUR package should've been deleted by the TU who promoted it to [community]. If there are outstanding changes not incorporated in the package, get in touch with the TU or file a feature request to propose those changes (think of it as a merge). Otherwise, if there is no difference, you can ask for it to be deleted. -- GPG/PGP ID: C0711BF1
Re: [aur-general] Merge request: projectm-jack
On 3 November 2013 12:02, Allen Li wrote: > It is possible to merge projectm-jack in the AUR with the one in > community? I am the maintainer for the package in the AUR, and there's > no need for it anymore since it is in community. > > Allen File a feature request at our bugtracker. -- GPG/PGP ID: C0711BF1
Re: [aur-general] Support for source mirror lists in PKGBUILD
On 2 November 2013 00:14, Ido Rosen wrote: > If metalinks/some external file are the only way to do this, you would need > a local source entry for the metalink / mirrors file AND a reference to > each file to pull from that metalink/mirrors file in the source array: (1) > This breaks something conceptually to me, since the PKGBUILD is no longer > the self-contained descriptor of where to get everything and how to put it > all together into the package, now you need this other file or that other > file at download-time (rather than just at prepare()/build()/package() > time). (2) It also is less KISS than just having multiple source array > entries for a mirrored file, since the packager and the person reading the > package now need to understand another file format to parse out where the > file is coming from. (3) Since there are extra files you're carrying along > and it's not clear that those files are only needed at prepare() or build() > time, now they're needed at initial download time, and the ordering of the > source array becomes important, since you need the metalink/mirrors local > file before the metalink link itself... For metalinks and such, yeah. But in my proposed scheme, the .mirrors file would contain only alternative links. The primary links would still be part of the source array. This is how I envision the structure:
Re: [aur-general] Support for source mirror lists in PKGBUILD
On 1 November 2013 18:58, wrote: > Are you trying tio re-implement Metalinks? They have become standartized way > to do what you want ages > ago. They are even supported by curl! Add metalink file to package (or > reference one from upstream), > redefine DLAGENTS to something like 'metalink::/usr/bin/curl --metalink %u' > and, if possible, convince > makepkg developers to add that DLAGENT to default makepkg.conf. Voilà, no > one's KISS principles > violated. IMHO, this sounds better than a buildscript full of hyperlinks. Alternative mirrors should be an optional feature. I'd even go as far as to suggest just having a .mirrors file (lowercase to differentiate it from pacman files) with a list of optional locations for each source, while adding a bit of code to makepkg to go through the list if the primary source locations fail for whatever reason. But that's my uninformed opinion. -- GPG/PGP ID: C0711BF1
Re: [aur-general] please remove lib32-wineasio
On 30 October 2013 10:22, Joakim Hernberg wrote: > I created https://aur.archlinux.org/packages/lib32-wineasio/ by > mistake. It's not needed so please remove it. Sorry for the noise! Done. -- GPG/PGP ID: C0711BF1
Re: [aur-general] Trusted User Application
On 28 September 2013 03:21, Evgeniy Alekseev wrote: > In order not to seem like a bearded nerd sometimes I listen music > and read Robert Jordan's or George R.R. Martin's books (or other similar). =) That doesn't sound any less bearded nerd :P I find you competent enough and feel that you have the right attitude, so good luck! -- GPG/PGP ID: C0711BF1
Re: [aur-general] pandoc moved back to the AUR for the time being
On 19 September 2013 05:40, Daniel Micay wrote: > I've moved pandoc back to the AUR because the latest version picked up too > many new dependencies. It was convenient to have it in [community], but > it's much saner to maintain these with the automation used by the > arch-haskell project. > > I only use it for Rust's documentation generator, and don't want to be > frequently rebuilding 30+ libraries for a language I don't use. > > Our packaging standards don't make much sense for Haskell because there are > little gains from dynamic linking. There's not nearly enough sharing of > code for it to come close to being efficient, and no stable ABI either. That's a shame, I am really dependent on it these days. But thanks for maintaining it until now :) -- GPG/PGP ID: C0711BF1
Re: [aur-general] uppity replaces curlpaste in [community]
On 18 September 2013 06:18, Xyne wrote: > Jonathan Steel wrote: > >>$_gitname is $srcdir/$_gitname, not $startdir/$_gitname, so it's fine. To >>double-check I set $SRCDEST to point somewhere else and it builds fine >>still. > > You're right. Looking at the source of makepkg, I see now that all functions > cd > into $srcdir. I still prefer the "$srcdir/$_gitname" format as it is explicit > and future-proof, but there is currently no technical reason to do so. I was told by at least one pacman dev (can't quite recall who or via which communication channel) that this practice should not be obsoleted; we should continue to navigate into $srcdir before doing anything. -- GPG/PGP ID: C0711BF1
Re: [aur-general] MSN Messenger and Google Reader
On 17 August 2013 11:08, Connor Behan wrote: > On 16/08/13 07:17 PM, Karol Blazewicz wrote: >> Windows Live Messenger (formerly MSN Messenger) has been deprecated. >> Is it OK to remove the various MSN clients from the AUR? >> What about programs relying on the discontinued Google Reader? > > Google Reader yes, MSN no. The servers are supposed to still work for a > year. > For some dates, look here: http://social.msdn.microsoft.com/Forums/live/en-US/44ad3195-6e7e-4192-95e5-bf5f282eab01/support-for-xmpp-ends-in-october-2013 -- GPG/PGP ID: C0711BF1
Re: [aur-general] [tu-bylaws][PATCH]
On 11 August 2013 18:29, Xyne wrote: > The current by-laws try to automate a process that requires human discretion. > This version retains automation for extreme cases and relies on human > discretion for the rest. Alright, this justifies those changes. Good to go on the rest, AFAICS. -- GPG/PGP ID: C0711BF1
Re: [aur-general] [tu-bylaws][PATCH]
On 9 August 2013 19:29, Xyne wrote: > ... > * remove distinction between "active" and "inactive" TUs So now what happens when so-called active or inactive TUs do not vote and prevent quorum from being established? No action is taken? I see these changes cover disappearing TUs, but not non-participating TUs. I may also just be missing something. > ... > * various changes to correct or improve English throughout the document While you're at it: > ... > mailing list] (aur-general). The proposal must also be worded unambiguously, > and such that a YES or NO answer may be given. -and such that +such that > ... > 2. quorum was established and the number of NO votes is greater than or equal > to the number of YES votes -quorum was established +quorum has been established > ... > +Quorums were established to ensure that all matters decided by vote are > +representative of the TU group. All TUs are expected to participate in all The terms "quorum" and "established" are already used in the document with a different meaning, so different wording could be used here, e.g.: +Quorums ensure that matters decided by vote are +representative of the voters as a group. All TUs are expected to participate in all > +A motion must be made by at least two TUs for the removal of a > +TU. The motion must be sent to -removal of a +removal of another > https://mailman.archlinux.org/mailman/listinfo/aur-general[aur-general], and > contain a detailed and valid reason that the TU in question should be > removed. -that the +why the > +OR who has not voted in a consecutive series of voting periods, the starting How many "consecutive series"? > +is followed by a discussion period of three days, a quorum of 66%, and a > voting -three days +3 days -- GPG/PGP ID: C0711BF1
Re: [aur-general] TUs and their following of the Bylaws
On 7 August 2013 20:11, Angel Velásquez wrote: > Supa easy, open the TU panel at the AUR, check who voted and who didn't > on the lasts SVP (the last three or more if you want) .. make some > decision about it, yeah we made the quorum but still, what about these > people that is marked as active, do packaging stuff but are working > isolated of the team? (seems to don't care about who we add or who we > remove). Whatever the perceived problems, it is important to remember that the present bylaws allow three consecutive _failed_ quorums before any TU is brought up for removal. Also, if quorum is not established then a second vote ensues. We don't really have to do anything on top of those. The problem as I see it is basically manual procedures that can be replaced by automation. (Before, it was worse; folks voted through the ML!) -- GPG/PGP ID: C0711BF1
Re: [aur-general] [tu-bylaws] [PATCH] Honor TUs who become active/inactive during votes
On 7 August 2013 06:06, Lukas Fleischer wrote: > The total number of TUs isn't fixed. It changes from time to time and it > might change during a SVP. I agree that it is a rare case but why not > find a proper way to handle that while we're talking about it... OK, I was just pointing out what looked most obvious to me, in a simple way (take the static number, purposely prevent it from changing by ignoring additions/removals during the vote). > >> [...] >> * Record active at start, add newly active, ignore newly inactive, >> ignore newly added, ignore newly removed > > So we're ignoring the fact that adding/removing a TU during the SVP > distorts the results? Because it is a corner case? In that option additions/removals are not counted at all (towards quorum) -- they are exempt. You can, of course, include newly added but ignore newly removed, following the active/inactive policy. This was just a suggestion. All we need is a reasonable (read: pragmatic) system to bring new people on board to do things in their spare time, so it's fine to not take it _too_ seriously. Do whatever it takes to automate the process; the bylaws just prevent us from f*ing up at certain times. -- GPG/PGP ID: C0711BF1
Re: [aur-general] [tu-bylaws] [PATCH] Honor TUs who become active/inactive during votes
On 7 August 2013 04:54, Rashif Ray Rahman wrote: > I think we need more opinions. Xyne? Anyway, if anyone's looking for > some bylaw amendment history: > > https://mailman.archlinux.org/pipermail/aur-general/2007-December/000127.html > https://mailman.archlinux.org/pipermail/aur-general/2010-December/012196.html > https://mailman.archlinux.org/pipermail/aur-general/2010-December/012534.html Sorry, this was somewhat off-topic to the discussion, in reference to Seblu's suggestion to drop the term 'active'. -- GPG/PGP ID: C0711BF1
Re: [aur-general] [tu-bylaws] [PATCH] Honor TUs who become active/inactive during votes
On 6 August 2013 20:19, Lukas Fleischer wrote: > On Tue, Aug 06, 2013 at 01:12:32PM +0200, Sébastien Luttringer wrote: >> On Tue, Aug 6, 2013 at 11:45 AM, Lukas Fleischer >> wrote: >> > On Tue, Aug 06, 2013 at 08:24:20AM +0800, Rashif Ray Rahman wrote: >> >> On 6 August 2013 05:53, Lukas Fleischer wrote: >> > >> > Any other opinions? >> Yes, we should drop completely the active statement. This requires a separate proposal. >> This will simplify computation and restore the purpose of the quorum! >> >> "requirement for a quorum is protection against totally >> unrepresentative action in the name of the body by an unduly small >> number of persons." >> (c) Wikipedia >> >> If you think the quorum is too high, it's better to reduce it (or remove it). >> Currently it's 66%, that means 33% of voters can be in holidays, in >> hospital, in travels and don't have in a 2 weeks time frame a way to >> read some mails and vote. >> In absolute it means : 12 TUs on 36 doesn't have time to vote. >> So, to take a decision we need at least 13 voters ((36-12)/2+1) on 36 TUs. >> That means we need a bit more than 33% of the total TUs to have a >> motion pass. I'm not sure it's necessary to change this. >> >> What you suggest is automatic hijacking of the quorum, in purpose to >> reducing the number of voters. >> With the new system, we can have a motion pass with 1 voters if every >> TU goes a the next fosdem :) > > I didn't think of it like that but I tend to agree now... Does anybody > disagree? +0 The hypothetical one-TU-rules-all case has been brought up before, but I can't cite any discussion or conclusion. > Anyway, we still need to find a way to count the total number of TUs. > That number needs to be recorded at some point of time during the vote. The total number of TUs is a recorded statistic in the AUR, AFAICS. Or are you referring to something else? > Options: > > * Record at the beginning, do not update if new TUs appear. > * Record at the beginning, fix if TUs are added/removed during the SVP. > * Record at the beginning, exclude new TUs from running votes. > * Record at the end. > > The first and last option might yield bogus results. If there this one > TU when the SVP starts and another one is added during the SVP, there > might be a quorum of 2 / 1 = 200%. Same if the number is recorded at the > end and a TU is removed during the SVP. > > The second option means that we record the total number of users that > have had TU status at some point of time during the voting period. By "new" and "added", do you mean newly appointed, or newly active? This is an important distinction. If we're still talking about active/inactive and this proposal: * Record active at start, add newly active, ignore newly inactive, ignore newly added, ignore newly removed > What do you think? I think we need more opinions. Xyne? Anyway, if anyone's looking for some bylaw amendment history: https://mailman.archlinux.org/pipermail/aur-general/2007-December/000127.html https://mailman.archlinux.org/pipermail/aur-general/2010-December/012196.html https://mailman.archlinux.org/pipermail/aur-general/2010-December/012534.html > >> >> Cheers, >> >> -- >> Sébastien "Seblu" Luttringer >> https://www.seblu.net >> GPG: 0x2072D77A -- GPG/PGP ID: C0711BF1
Re: [aur-general] [tu-bylaws] [PATCH] Honor TUs who become active/inactive during votes
On 6 August 2013 05:53, Lukas Fleischer wrote: > Instead of counting the number of active TUs when a vote begins, update > the number whenever a TU becomes active/inactive during a voting period. What happens when a TU becomes inactive after casting a vote? Would her vote be invalidated? If so, no change is needed to the bylaws. Otherwise, another line of explanation would help prevent ambiguity... > In the context of SVP, TUs are considered active if they are marked as active > -when the voting period ends. > +at some point in time during the voting period. In the context of SVP, TUs are considered active if they are marked as active -when the voting period ends. +at any point during the voting period. TUs who become inactive during the +voting period are not considered inactive until the end of the running SVP. -- GPG/PGP ID: C0711BF1
Re: [aur-general] TUs and their following of the Bylaws
On 5 August 2013 07:00, Lukas Fleischer wrote: > I don't really like the idea of having to specify an exact end date. If > you are inactive due to, say, a long hospital stay or a lack of an > internet connection after moving you will have to update the end date > continuously. Being inactive usually means that you're offline most of > the time so this might turn out to be a real burden. Yes, having to set specific dates is not practical at all. I was more concerned about doing away with e-mail, but I suppose it can remain a necessary manual step. So, the procedure would be as follows: 1. Send an e-mail to the list to declare inactivity 2. Mark yourself as inactive in the AUR web interface If we enforce this, then the bylaws need no amendment. In this case, (2) simply becomes a more convenient way to record inactivity (compared to, say, editing a wiki page). > Another suggestion: Count every TU that is active during the voting > period (no matter when, no matter how long). That is pretty simple to > implement: Store all active TUs when a vote starts, add a TU to that > list (for all running votes) whenever he becomes active. Fair enough. I don't think we need to care about those who mark themselves inactive during a vote -- they will simply have to remember to vote before changing their status or be treated as a defaulter (active but did not vote). This may require changing the bylaws. Even at present, given that a status can be changed any time, counting at the end of the vote would theoretically disqualify those who were active at the start, voted, and then marked themselves inactive. -- GPG/PGP ID: C0711BF1
Re: [aur-general] TUs and their following of the Bylaws
On 4 August 2013 21:35, Lukas Fleischer wrote:
> Trying to automate this, I just submitted a couple of AUR patches to
> aur-dev [1].
>
> Based on this, we could:
>
> * Add another simple patch that simply displays whether a vote is
> accepted or not. This leaves no room for discussion on the results of
> future votes.
>
> * Implement auto-initiation of removal procedures for repeated quorum
> offenses.
>
> That do you think about that?
Excellent, but it looks like there's a problem with when the status
should be counted. We must allow a TU to become active during a vote
-- it will simply be wrong to deny her the right to vote simply
because she was not active at the start.
An inactivity status must have an accompanying duration, be it a real
input (start, end date), informative text ("Holidays til sept"), or an
e-mail (as is presently warranted by the bylaws). Having an input
complicates the automation, but an e-mail also becomes manual burden.
The case of an MIA is different. There may not be three consecutive
votes during the period of absence, so automatic removal won't happen.
The removal must be proposed based on other activity criteria, such as
(lack of) packaging. So this cannot be automated.
All of these are not set in stone -- the bylaws can be modified to
better fit an automated system. To begin with, it must be modified if
the proposed changes are committed verbatim (defining activity status,
removal procedure), subject to a vote.
--
GPG/PGP ID: C0711BF1
Re: [aur-general] TUs and their following of the Bylaws
On 3 August 2013 02:40, Angel Velásquez wrote: > Hi people, > > First of all, i'm writting this mail as an ex TU and user, not as a dev > who want to push you how to proceed or follow the bylaws. > > Having that set, I am shocked about how the bylaws are being just used > just for addition process, but for somehow are being ignored for stuff > like quorum and removal procedures, some TUs look to otherside when we > mention this subject. > > So, what's the point of having a Bylaw if you will not follow it?, why > don't modify it and remove that part that you don't want to be aware?, > being a TU is not about just delivering packages and orphaning / > splitting packages on the AUR, TUs must work as a group, and it used to > be like that when I was part of the team (I still feel part of the team > but seems that oficially I am not a TU, a corner case that is not well > documented on the Bylaws btw). > > So, according to that, I don't want to say names (i did said those names > on the irc channel when I found the quorum situation on the last SVP but > as I've said nobody react .. bad bad bad, guys.. dissapointing I must > say), but I still feel that TUs must do that, not a guy which is not > completely a TU -yes, me-. > > Please check the last SVP and check who didn't voted, and some TU call > the rest of the group for either following the Bylaws, or call for a > modification of these Bylaws and allow these cases. > > In my opinion, (now as a dev) we don't want to control what you do, > because we as a user and devs trust a group of people that have their > own defined rules, but if the TUs won't start following these rules, is > simply stupid to have these rules there. > > Please don't kill the messenger, this is nothing personal against anyone > or the group, I really appreciate most of the people who contribute to > the Arch Linux project and I am grateful as an user for that. > > Let this discussion begin. There is simply no-one taking initiatives any more. I think the bylaws are fine, but if anyone objects to any particular clause we are able to motion for amendment. We are also able to motion for the removal of a TU. Ionut once digged out repeated "offenders", sent some warnings, but that's about the last of such things that I remember. We also had removals that ended successfully. So, someone just needs to point out those who have been MIA. -- GPG/PGP ID: C0711BF1
Re: [aur-general] TU application
On 28 July 2013 02:49, Rashif Ray Rahman wrote: > We simply cannot ignore the bylaws. This serves as a reminder to show > us all the numbers when declaring results. And I failed to provide that myself: 24/36 = 0.66 ... = ~0.67 > 0.66 > according to this list, we have 36 active TUs. s/have/would have/ The list has not been updated to reflect recent modifications (additions and deletions within the total) to the team, but the fact remains that at least one out of a supposed 37 TUs (less if we missed any recent resignation) is inactive. On 28 July 2013 03:04, Bartłomiej Piotrowski wrote: > On 2013-07-27 20:49, Rashif Ray Rahman wrote: >> according to this list, we have 36 active TUs. > > Actually I see 35 TUs there, 33 without Daenyth and xyproto. Even better, then ;) > It seems like a good opportunity to determine what does "active TU" mean > – some Trusted Users, even if active in packaging terms, simply ignore > our votes. When do we consider someone as active? When he updates, fixes > and rebuilds his packages in reasonable time or doesn't forget about voting? > > If we care about all the duties, should we remove partially inactive TUs? Our bylaws are clear on this - the "automatically brought up for removal procedure" means that there is no argument towards having a removal vote - so we should start a vote (but we can also prevent the removal by all voting YES). I think the bylaws are also clear that we are to decide on the activity status by memorising e-mails to the mailing list. The wiki page is some sort of a manual tally for that. However, despite the clarity, the method is no doubt cumbersome. We need automation. -- GPG/PGP ID: C0711BF1
Re: [aur-general] TU application
On 28 July 2013 01:53, Xyne wrote: > I'm sorry to have to point this out, but the proposal has not been accepted > according to our bylaws. Xyne, thank you for actively verifying the result of the vote. You remind me of Loui, who used to be very particular about these things. We simply cannot ignore the bylaws. This serves as a reminder to show us all the numbers when declaring results. Anyway, I think the candidate is lucky this time. AFAIR, we get our list of "active" TUs from a wiki page [1] (not really elegant, but it's what I know to be the only real tally of the thing) and, according to this list, we have 36 active TUs. So, really close call, but quorum has been established and the number of YES votes are greater. [1] https://wiki.archlinux.org/index.php/Trusted_Users -- GPG/PGP ID: C0711BF1
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] About orphaning all packages of inactive users
On 19 July 2013 05:24, Alexander Rødseth wrote: > I'm also interested in comments about what should be done for similar > situations in the future. I assume most users would be happy just to > see the pacakges being updated instead of hoarded and would think it > was fine if TUs just orphan them after a similar investigation of the > situation. We could do an automated cleanup again, like we did a while ago thanks to Jakob Gruber (schuay): https://mailman.archlinux.org/pipermail/aur-general/2010-October/011193.html -- GPG/PGP ID: C0711BF1
Re: [aur-general] Guake-Solarized-Colors
On 29 May 2013 18:35, Maxime Gauduin wrote: > What Felix said. Also such a simple patch can be achieved with a sed > command. Just a note here: While the above is true for simple one-liners, I would recommend against getting in the habit of using sed to accomplish patching. A proper patch is much cleaner and conveys the message better. A patch knows exactly what to do, but with the sed command you may not. -- GPG/PGP ID: C0711BF1
Re: [aur-general] Fwd: please add -depth 1 to makepkg git clone
On 7 April 2013 09:19, Tai-Lin Chu wrote: >>Okay, if you're going to be doing shallow clones, you may as well just > get the dang tarballs. This is totally flying in the face of what the > -git packages really are, development packages. Once you download it, > you never have to again, just update it. If you've got a problem with > the size, then somehow get a physical copy of it, or just take the time > to get a revision, then keep it updated gradually. > > no. because there is no snapshot tarball available all the time, we > use git clone. Before this goes on indefinitely, know that aur-general is not the right medium for this sort of arguments. Better discussion based on technical merit can be had through the pacman-dev mailing list or our bugtracker. If you have a case, let the right people judge it. -- GPG/PGP ID: C0711BF1
Re: [aur-general] VCS PKGBUILD and Pacman 4.1: increase epoch?
On 6 April 2013 18:21, Cédric Girard wrote: > On Fri, Apr 5, 2013 at 11:49 PM, Jan Alexander Steffens wrote: >> The problem is that makepkg will update the pkgver of the downloaded >> PKGBUILD, so there is no reliable way of detecting an update without either >> bumping the epoch, or storing another copy of the downloaded PKGBUILD. > > Updating the epoch each time seems a little too much. epoch does not > seems to be designed for this. > > What I was speaking about is increasing the epoch when switching from > one versioning scheme to another. > I have taken the decision to do it. > The reason is not about AUR helper. It is about consistency. Pacman is > not aware from where your installed packages come from. It thus does > not seem logical to generate new package version that are smaller than > the old one and pretending they provide more recent version of the > software. You are correct. Use epoch only where and when necessary -- do not abuse it. Its sole purpose is to ensure updated packages are treated as 'upgrades' even when their version according to, say, vercmp, is lower than the older package. Epoch should then be introduced, but it need not be bumped unless the versioning scheme changes once again. However, keep in mind that once epoch is introduced, it must always remain (even if at 1). -- GPG/PGP ID: C0711BF1
Re: [aur-general] Fwd: please add -depth 1 to makepkg git clone
On 6 April 2013 15:25, Tai-Lin Chu wrote:
> yes, i agree with you. But as a person who commits patches and needs
> to test, I think using --depth 1 makes initial cloning faster and
> decreases the load of remote git server. Think about this 100 people
> clones vlc.git with shadow (around 600mb) vs without shadow (around
> 1mb)... its not just about whether you care it or not; please
> preserve resources of other projects.
I personally like small checkouts. If I am testing software, I don't
really need much of its history, and I don't need to be able to commit
anything. If I'm developing software, I'll have a separate directory
with full checkouts anyway. VCS differences apply, though.
There is really no pragmatic difference between copying with cp and
exporting (Subversion) or cloning (Git) a VCS repo, except when you
don't know what you're doing. If you make changes, a cp may not copy
what you intend to copy, or vice-versa with export/clone.
IMO, keeping checkouts lean and mean for building experimental
packages is a good idea. VCS repos take a lot of space, and in the
event you want to maintain package repos with them, you'd like the
extra space saved.
However, we need equivalent methods for every VCS we care to support
('depth' doesn't mean the same thing in svn, for instance), and we
need to provide a mechanism to choose to keep depths (so that you may
choose to reuse repos for your own use with full history and what
not).
--
GPG/PGP ID: C0711BF1
Re: [aur-general] realtimeconfigquickscan merge request
On 1 April 2013 05:26, Rob Til Freedmen wrote: > https://aur.archlinux.org/packages/realtimeconfigquickscan/ > orphaned & build from an outdated repo; 18 votes > > https://aur.archlinux.org/packages/realtimeconfigquickscan-git/ > maintained by hermes14 & build from a current repo; 7 votes > > https://aur.archlinux.org/packages/realtimeconfigquickscan-hg/ > maintained by hermes14 & build from an old repo; 5 votes > > There is no stable release - only available from git > so I would prefer realtimeconfigquickscan as the sole package name Alright, commented on the second package. Will delete that one after he has adopted the first. Already deleted the third. -- GPG/PGP ID: C0711BF1
Re: [aur-general] TU application from graysky - voting period
On 25 March 2013 03:30, Xyne wrote: > Sébastien Luttringer wrote: > >>> Objections were raised and then countered with arguments. If anyone felt >>> that >>> the objections were still valid after that then they should have replied >>> with >>> their reasons. That is the point of the discussion period: to discuss the >>> issues and reconsider them in the light of the evolving conversation. It >>> gives >>> the candidate the chance to respond and adapt as well. If anyone felt that >>> my >>> reply to Dave failed to address the issues then they should have stated >>> why. No >>> one did. >>You explain again your former opinion. >>It's not because you are the last one to answer that you convince everyone. >>It's not because I will not give arguments to refute what you say that >>you convince me or others readers. > > I think we have different definitions of "discussion". > > I would also say that if you have no arguments to support an opinion then it > is > baseless and should be re-examined. Well, whatever the case, we know that: 1. Sébastien (seblu?) is the best example of a TU who was rejected at one time 2. Dave (falconindy) is _not_ to "blame" (he did the right thing by being transparent) 3. Those who silently thought Dave must be right need a change of attitude The current (majority) voting system is fine -- making decisions based on consensus agreement is not a suitable method for the TU selection process (it would needlessly raise the bar for something that is not a matter of public safety). Voting systems should eliminate bias, and in this case it did not favour any one particular outcome (mixed opinions), so it in fact worked pretty well. If an opinion was influential, then so be it. You can't disregard the result just because you did not expect it (I didn't either). However, all these indicate that grasky is good to go for the next round (after three months), so let us all not worry and continue what we were doing. I'd personally like him to reapply when that time comes. Til next time, then ;) -- GPG/PGP ID: C0711BF1
Re: [aur-general] LV2 needs an update and a new maintainer.
On 20 March 2013 02:11, Rob Til Freedmen wrote: > Forgot the package link > https://www.archlinux.org/packages/extra/i686/lv2/ Sorry, that should've been me. I don't know how or when this became an orphan, but most probably if it's not a bug then I really did not adopt it since I did the rename from lv2core to lv2. Thanks for the heads-up! -- GPG/PGP ID: C0711BF1
Re: [aur-general] TU application from graysky
On 12 March 2013 04:24, member graysky wrote: > Hi All. Inspired by Allan's talk @ SINFO XX, I decided to throw my > hat into the ring and formally apply to be a TU. My linux history > started with RH and SUSE over a decade ago. I discovered Debian and > Ubuntu. I found myself wanting more control and up-to-date repos and > discovered Arch. I find it and its underlying philosophies, and its > community to be to my liking. I have an interest in giving back to > the Arch Community though maintaining some packages in [community]. > Listed below are a few of my contributions for those of you who don't > recognize me from the bbs or from other interactions. I reached out > to Xyne who kindly agreed to sponsor my candidacy for TU. The username "graysky" sounds familiar to me, but it doesn't register anything negative. At one glance, though, I can derive at least one fact -- there have been applicants in the past much less competent. As such, I do not see competency as an issue in this application. If Xyne is the sponsor, then I can rest assured of the applicant's competency. Nitpicking here is unnecessary. However, feedback regarding attitude is important, and it should be taken into consideration. Experiences and interactions vary, so do opinions and interpretations, but that is why we vote. Anyway, good luck grasky! -- GPG/PGP ID: C0711BF1
Re: [aur-general] [arch-general] Winter Cleanup of [community]
On 29 January 2013 19:02, Alexander Rødseth wrote: > A TU that pays extra care to packages that are well suited for blind > users would be an asset for Arch Linux. > And for several years that person was Chris :) -- GPG/PGP ID: C0711BF1
Re: [aur-general] TU Application - Daniel Micay (thestinger)
On 7 December 2012 02:34, wrote: > I began contributing back to the community in 2010 by putting my efforts into > improving the wiki, and in September of 2011 I joined the ArchWiki > administration team. Oh, the mysterious wiki guy! -- GPG/PGP ID: C0711BF1
Re: [aur-general] Deletion request: knfoviewer
On 8 November 2012 11:14, Limao Luo wrote: > and, looking at the project, all it does is display ASCII .nfo files > without garbling the ASCII art; it can be replaced by something as simple as > cat. Btw there is nfoview in community, though not a Qt/KDE (or GNOME) app; just simple GTK3. I believe it's the only active project of its kind. -- GPG/PGP ID: C0711BF1
Re: [aur-general] ibus orphans in [community]
On 17 October 2012 02:05, Yichao Yu wrote: > On Tue, Oct 16, 2012 at 1:47 PM, Yichao Yu wrote: >> On Tue, Oct 16, 2012 at 1:30 PM, Rashif Ray Rahman >> wrote: >>> On 17 October 2012 00:55, Allen Li wrote: >>>> Hi, >>>> >>>> I would like to point out that ibus does Japanese and Korean, whereas >>>> fcitx only does simplified Chinese (at least according to the wiki). >>>> Thus ibus is one of the only input options for those languages on arch >>>> at the moment (barring that other one whose name I'm having trouble >>>> recalling at the moment, which I found inferior to ibus), so dropping it >>>> is extremely unfavorable I think. >>>> >>>> Just my two cents. >>>> >>>> Allen Li >>>> >>>> On Tue, Oct 16, 2012 at 05:30:30PM +0200, Alexander Rødseth wrote: >>>>> Hello, >>>>> >>>>> >>>>> ibus is used for keyboard input for a few major non-English languages. >>>>> >>>>> Several of the ibus packages has been unmaintained for a while now: >>>>> https://www.archlinux.org/packages/?sort=&repo=Community&q=ibus&maintainer=orphan >>>>> For instance, ibus-sunpinyin, was last updated almost a year ago >>>>> (2011-10-02). >>>>> >>>>> These ibus-packages have survived at least one package-cleanup, being >>>>> neither adopted nor moved. >>>>> While there is interest amongst the trusted users to maintain these, >>>>> none of the trusted users are currently using ibus. >>>>> >>>>> After visiting #archlinux-cn, a couple of friendly people expressed >>>>> interest in maintaining the ibus packages, but they had only few >>>>> packages on AUR to show for. >>>>> I also learned that mostly, fcitx (currently in [extra], is used >>>>> instead of ibus). Dropping ibus could have been an option, but I also >>>>> heard rumors that ibus will be a dependency of gnome-settings-daemon. >>>>> >>>>> There is also a canidate for asking to maintain the ibus packages, >>>>> that has not yet been contacted, but which already maintains several >>>>> related packages on AUR: >>>>> https://aur.archlinux.org/packages.php?K=yangtsesu&SeB=m >>>>> >>>>> If you think that his packages look ok, my plan is to contact >>>>> yangtsesu and ask if he wants to maintain the ibus packages in >>>>> [community] (and thus becoming a TU). >>>>> >>>>> If you know of other canidates that have a comparable selection of >>>>> relevant AUR packages, please let us know who they are. >>>>> >>>>> Please correct me if any of the above is incorrect or let us know if >>>>> you have additional information. >>>>> >>>>> Sounds like a plan? >>>>> >>>>> >>>>> -- >>>>> Cordially, >>>>> Alexander Rødseth >>>>> Arch Linux Trusted User >>>>> (xyproto on IRC, trontonic on AUR) >>> >>> Also, fcitx looks very CJK-specific to me, whereas ibus is a >>> multilingual input bus (think SCIM). So, not really directly >>> comparable. I'm all for finding someone to maintain the stuff, be it >>> in the repos or AUR. >> >> No, fcitx is also not cjk-specific at all. There is fcitx-keyboard >> (which is already merged into fcitx itself) that you can use keyboard >> layout as input method to input all languages that just need a layout >> switching. It also has spell check/hint(as you can see on the fcitx >> wiki main page..) which ibus cannot provide. Here[1] is also a list of >> input method fcitx support now (basically covers all major input >> method ibus supports). Yes most of them are Chinese input method but >> that's because Chinese input method is the single most complicated >> one. (also true for ibus). >> >> Yes the original name of fcitx suggest it is a Chinese input method >> but it is not anymore now >> >> And no, I am not talking about dropping ibus packages (taking into >> account the *stupid* thing gnome3.6 have been doing on input method >> integration, it might not be a good idea to move those into AUR >> either..). Just want to clarify that fcitx is not CJK specific (in >> fact it provides more non-CJK specific features than ibus and
Re: [aur-general] ibus orphans in [community]
On 17 October 2012 00:55, Allen Li wrote: > Hi, > > I would like to point out that ibus does Japanese and Korean, whereas > fcitx only does simplified Chinese (at least according to the wiki). > Thus ibus is one of the only input options for those languages on arch > at the moment (barring that other one whose name I'm having trouble > recalling at the moment, which I found inferior to ibus), so dropping it > is extremely unfavorable I think. > > Just my two cents. > > Allen Li > > On Tue, Oct 16, 2012 at 05:30:30PM +0200, Alexander Rødseth wrote: >> Hello, >> >> >> ibus is used for keyboard input for a few major non-English languages. >> >> Several of the ibus packages has been unmaintained for a while now: >> https://www.archlinux.org/packages/?sort=&repo=Community&q=ibus&maintainer=orphan >> For instance, ibus-sunpinyin, was last updated almost a year ago >> (2011-10-02). >> >> These ibus-packages have survived at least one package-cleanup, being >> neither adopted nor moved. >> While there is interest amongst the trusted users to maintain these, >> none of the trusted users are currently using ibus. >> >> After visiting #archlinux-cn, a couple of friendly people expressed >> interest in maintaining the ibus packages, but they had only few >> packages on AUR to show for. >> I also learned that mostly, fcitx (currently in [extra], is used >> instead of ibus). Dropping ibus could have been an option, but I also >> heard rumors that ibus will be a dependency of gnome-settings-daemon. >> >> There is also a canidate for asking to maintain the ibus packages, >> that has not yet been contacted, but which already maintains several >> related packages on AUR: >> https://aur.archlinux.org/packages.php?K=yangtsesu&SeB=m >> >> If you think that his packages look ok, my plan is to contact >> yangtsesu and ask if he wants to maintain the ibus packages in >> [community] (and thus becoming a TU). >> >> If you know of other canidates that have a comparable selection of >> relevant AUR packages, please let us know who they are. >> >> Please correct me if any of the above is incorrect or let us know if >> you have additional information. >> >> Sounds like a plan? >> >> >> -- >> Cordially, >> Alexander Rødseth >> Arch Linux Trusted User >> (xyproto on IRC, trontonic on AUR) Also, fcitx looks very CJK-specific to me, whereas ibus is a multilingual input bus (think SCIM). So, not really directly comparable. I'm all for finding someone to maintain the stuff, be it in the repos or AUR. -- GPG/PGP ID: C0711BF1
Re: [aur-general] python-foo and python2-foo - should they conflict?
On 16 October 2012 16:48, Oon-Ee Ng wrote: > python-foo and python2-foo - should they conflict? Absolutely not. At least, ideally. I may work with both Python versions and in that case will need libraries for each. Shared files have been a problem, and so far the (painful) route is to split them into a -common package (since upstream does not care to handle such inconveniences). See pyqt for an example. -- GPG/PGP ID: C0711BF1
Re: [aur-general] TU resignation: Chris Brannon
On 7 October 2012 23:30, Chris Brannon wrote: > Hello all, > I regret that it has come time for me to resign from Arch Linux, at > least for now. I have a lot of things going on in my life, with a new > job, a major cross-country move, and so forth. I haven't really been > attending to my Arch responsibilities, and that isn't really good for > Arch. I hope to be able to reapply at some later date. The list of my > packages is at the bottom of this message. Anyway, it has been fun. > The Arch Linux community is great. It's one of the greatest things > about this distro. > > PS. I'll continue maintaining my TalkingArch project. People who are > using it needn't worry. > > -- Chris > > List of packages: > 9base > bsd-games > cdcd > cdck > cddb_get > curlftpfs > cxxtest > ddclient > dtach > dumb > epydoc > esekeyd > espeakup > flac123 > gnormalize > jython > libxml-perl > luadoc > luafilesystem > luajit > lualogging > luarocks > mget > mldonkey > ndisc6 > perl-file-nfslock > perl-freezethaw > perl-net-smtp-ssl > plan9port > python2-pyparsing > python-flup > python-foolscap > python-fuse > python-mechanize > python-mpdclient2 > python-musicbrainz2 > python-paramiko > python-pyparsing > python-webpy > sloccount > speakup-utils > tcpflow > urlgrabber > webfs > Hey Chris You will be missed, but it's all for the best (congrats on the new job; well worth the move). Take care and good luck! -- GPG/PGP ID: C0711BF1
Re: [aur-general] away
On 2 August 2012 00:30, Ike Devolder wrote: > Op woensdag 1 augustus 2012 12:15:43 schreef Stéphane Gaudreault: >> -BEGIN PGP SIGNED MESSAGE- >> Hash: SHA1 >> >> Le 2012-08-01 12:04, Ike Devolder a écrit : >> > Op woensdag 1 augustus 2012 18:03:20 schreef u: >> >> Op woensdag 1 augustus 2012 11:49:58 schreef Dave Reisner: >> >>> On Wed, Aug 01, 2012 at 05:47:17PM +0200, Ike Devolder wrote: >> Op maandag 30 juli 2012 06:43:52 schreef Xyne: >> > Ike Devolder wrote: >> >> Hi, >> >> >> >> I'll be away for a couple of days, normally everything should get >> >> updated >> >> automatically while i'm out. >> > >> > How are you updating things automatically? >> > >> > >> > Regards, >> > Xyne >> >> cronjobs on a server :) >> i have to add more but most are already to be found: >> https://github.com/BlackIkeEagle/archbuild >> >> --Ike >> >>> >> >>> So you're blindly signing and pushing packages based on the fact that >> >>> they compile? >> >> >> >> yes why not ? >> >> >> >> --Ike >> > >> > i could modify the script that they land in community-testing first >> > >> > --Ike >> >> Compiling != Working, so I think it is a good practice for a maintainer >> to test packages before uploading them. >> >> In some case this could be difficult to do (eg massive rebuild for a >> libname change) and in these cases it is ok to "blindly" push package on >> the basis that is compile and test it later. In any case, I would expect >> that a package is minimally tested before it goes to the repos. >> >> Stéphane >> -BEGIN PGP SIGNATURE- >> Version: GnuPG v2.0.19 (GNU/Linux) >> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ >> >> iQEcBAEBAgAGBQJQGVYvAAoJEOpoNuGrRBGWT7QIALr88yM242d4ub4eQQQgZYJk >> Ub6M+6IYwzho8rkO6YwyoNDCREVBWCf30LBbCobBjeUy+s93BByhd9CG7UL9JBaa >> UtRc1LCKMczzmJheoH/fAdxHy+my6Ye8NaAh+v8vuK0pd86nJLxkw1TsSCcwtjSi >> +F4jLy/FrigkCClPFEY8CKDQY4pl6mbvP4NE559ufZHdLJQTlMMD0HLYCmedb2W4 >> OWbbMylmXGEmPL9Enx7nk67nh17HceAZVkIUKGwfx1SwWBdDynwZ4/eMISImpSX2 >> qoYOE5Th7c7I/zpXYRaDWzVzRR32rI4MZE8xsAjMV/kFR6UtQrhBp4vRsMWJIPM= >> =nVW1 >> -END PGP SIGNATURE- > > Well then i'll drop the auto-updaters for community. but in general i find > this > very handy. i'll leave the scripts in the git repo for now but i'll drop the > cronjob now. > > --Ike Automating like this is very bad practice. I believe a maintainer's job is to ensure that a package works before making it accessible to everyone. Of course sometimes we're guilty of assuming stuff "should probably just work" but let's not automate that attitude. Otherwise it's OK if you push these to a testing repo me thinks. But to do justice after you return you should check them one by one :P Also you can do this on a case-by-case basis depending on how often things are likely to break. Yet I think just auto building is fine but not auto pushing. -- GPG/PGP ID: C0711BF1
Re: [aur-general] TU Application - Andrzej Giniewicz (giniu)
On 13 July 2012 16:24, Andrzej Giniewicz wrote: > On 13.07.2012 07:41, Thomas Dziedzic wrote: >> With 13 yes votes, 1 no vote, and 5 abstain votes, I would like to >> welcome Andrzej (giniu) as a new tu. >> > > Thanks everyone, I hope we will have a wonderful time working (not to > mention partying!) together :) See you soon on IRC, as I promised, I > will surely drop by from time to time now! > > Andrzej. Welcome aboard! I would personally like to see you show some love for TeX and Arduino stuff in terms of packaging ;) -- GPG/PGP ID: C0711BF1
Re: [aur-general] TU Application - Daniel Wallace (gtmanfred)
On 10 June 2012 19:07, Jelle van der Waa wrote: > A list of AUR maintained packages would be useful, so below is the url. > > https://aur.archlinux.org/packages.php?O=0&K=gtmanfred&do_Search=Go&detail=1&C=0&SeB=m&SB=n&SO=a&PP=50&outdated= Jelle, it's there. Footnote no. 3. -- GPG/PGP ID: C0711BF1
Re: [aur-general] TU Application - Daniel Wallace (gtmanfred)
On 10 June 2012 11:23, Daniel Wallace wrote: > I don't really have any packages that I think > really need to be pulled to community, maybe at some point later, but I would > really like to > start making zsh completion for a lot of packages which do not have it > already. I could start > by maintaining the zathura plugins and the haskell-syb package. So your main contribution as you see it now would be zsh completion? -- GPG/PGP ID: C0711BF1
Re: [aur-general] jabref maintainer wanted
On 8 June 2012 15:18, Hector Martinez-Seara wrote: > It's a pitty as it is a very useful program basic for the work of many of us, > Hector It is indeed. If only it didn't look so crappy or there wasn't any alternative I would've bothered to adopt it. However, look forward to KBibTeX and maybe Mendeley Desktop. -- GPG/PGP ID: C0711BF1
Re: [aur-general] AUR and unsuported architectures
On 2 June 2012 11:21, Connor Behan wrote:
> On 01/06/12 08:17 PM, Hugo Osvaldo Barrera wrote:
>> Given that this question ("is arm/ppc allowed in AUR?") has had a bit
>> of mixed responses, can I expect a bit more of discussion on this, or
>> should I consider the "no" final? Thanks,
>
> I wouldn't consider the "no" final. If you put a PKGBUILD in the AUR
> that says arch=('i686', 'x86_64' 'arm' 'ppc') and someone requests that
> it be deleted for that reason, I'm not going to delete it.
Look at it this way: why the hell should it matter to me if I'm not an
'arm' or 'ppc' user? The build would go just fine, and if I never look
at the PKGBUILD, then nothing is different to me. So in the end,
there's nothing wrong with that if the same PKGBUILD can be used
across platforms.
--
GPG/PGP ID: C0711BF1
Re: [aur-general] TU application - speps
On 27 April 2012 03:26, speps wrote: > Since I'm involved into the Arch Audio project by submitting several build > scripts and binary packages to its repository, I'd surely add the most > popular > in [community] (ex. supercollider, csound, pd, lv2 plugins), and I would > help Ray Rashif maintaining the ones already there, of course. > > Being an out-of-the-box pro-audio ready distro (in terms of officially > distributed packages) would be great for Arch, since the number of > multimedia-oriented users, developers and projects using Arch as their > main platform is growing day by day (LAC 2012 has been a testimonial ;)). > > Also, I would contribute adopting and maintaining orphans and of course > taking care of bug reports. > I have worked with speps on a number of things and I find him to be capable and competent. If Thorsten didn't sponsor him I would have. I also never fully figured out why we insist on "real" identities or make it difficult for people like Xyne to participate freely. In fact, I don't think we have that as a requirement. You simply need to have a key and to sign your application, so that we can verify your other prior activities and create a hypothetical profile out of them. Displaying a real identity is a bonus. I believe our web of trust is flexible and works well. The final master key signature requires a real verified identity. The other keys are there to just show that most developers "trust" you to release packages. You may or may not verify yourself, but if you don't you won't get the last signature. It's a fair policy. Anyway, good luck! -- GPG/PGP ID: C0711BF1
Re: [aur-general] TU Application - György Balló
On 4 March 2012 00:12, Ionut Biru wrote: > Unity is only a Canonical project, not a project that can be used by anyone. It's just about accessibility, so as to not deprive anyone and allow no-one to say "there is no foo in Arch" :D But I guess if it's that much PITA then it should be forgotten about. -- GPG/PGP ID: C0711BF1
Re: [aur-general] TU Application - Ike Devolder
2012/3/2 Angel Velásquez : > Hi Ike! > > I didn't get you by your name but by your nickname, oh yeah, as Allan > said I had a good memory about you, so this is good ;). I've seen the nickname around as well, but not sure about what really. But that should be good after looking at a couple PKGBUILDs :) -- GPG/PGP ID: C0711BF1
Re: [aur-general] TU Application - György Balló
On 3 March 2012 11:38, Balló György wrote: > Hi, > > thanks for the question. > >> I looked at your AUR packages and saw that you are maintaining the >> unity desktop. I never used this desktop environment, but as a >> curiosity is it something you want to eventually bring into [community] ? > > I worked a lot on making Unity and indicators usable on Arch Linux, but > I don't want to add any of these packages[1] into [community], because > Ubuntu heavily patched gtk2, gtk3[2], metacity and compiz, and it's > impossible to build and/or use some packages with the upstream, > unmodified packages. They patched a lot of other packages also for > better integration into the panel and the launcher. > > So if GNOME developers accept some must have patches, then I could > imagine to add these packages, but until it does not happen, it's better > to keep them in a separated repo. (However I'm not sure that Ubuntu sent > all required patches to upstream yet.) > > > [1] Nearly all packages in ubuntu-unity and apps-unity directories on > https://github.com/City-busz/Arch-Linux-Repository > [2] E.g.: https://bugzilla.gnome.org/show_bug.cgi?id=658563 Is there a separate repo? Do you intend to start one otherwise? I would really like to see unity accessible for Arch users. Anyway, I don't know what all the fuss on workarounds is about, but I view "workarounds" as temporary fixes, nothing harmful. It is perfectly valid to work around limitations for which there is no current solution. -- GPG/PGP ID: C0711BF1
Re: [aur-general] Inactivity
On Feb 6, 2012, at 10:34 AM, Bartłomiej Piotrowski wrote: > > I'll be absent to end or (20th) of February, mostly because of my > mother's death. > > If someone wants, it would be nice to upgrade Kadu (0.10.1 → 0.11.0) and > rebuild nginx and winefish against new pcre. > > I will be available by e-mail, if you need something. My condolences. No matter how young or old you are, be strong and look towards the future. -- GPG/PGP ID: C0711BF1
