Re: [aur-general] Problem uploading packages on i686
On Sun, May 4, 2008 at 6:08 AM, Allan McRae <[EMAIL PROTECTED]> wrote: > Hi all, > > At the moment the is a problem uploading packages to i686 community. I > know this because I have moved a couple of packages to community and the AUR > does not reflect this after several hours. Yeah, I noticed this problem too. Yesterday I updated quite a few of my packages and added a new one (wavegain), but the last one I uploaded (aicrack-ng) is still not there. I'm wondering if it is my fault... I'll try to upload it again in a few minutes. > My question is, does the output from the community/AUR integration daemon > get posted anywhere visible to us TUs? I don't know, but it'd be a good thing. Corrado
Re: [aur-general] Problem uploading packages on i686
On Sun, May 4, 2008 at 6:31 AM, Allan McRae <[EMAIL PROTECTED]> wrote: > Well, I managed to send that once from each email address and the missing > package email arrived straight after :) Oh, no problem... I managed to answer your first mail before seeing this one and the AUR notify... -.- Corrado
Re: [aur-general] TU application
On Fri, May 2, 2008 at 12:30 PM, Dragonlord <[EMAIL PROTECTED]> wrote: > My AUR packages: > > http://aur.archlinux.org/packages.php?O=0&L=0&C=0&K=Dragonlord&SeB=m&PP=100&do_Search=Go Hi Jaroslav. As you may notice by your inbox I have checked a few random packages of yours. I didn't see anything particularly wrong (except for tome, however I'm confident you'll fix it soon). Generally I think you are a good packager, skillful enough and fast at fixing things when needed, however take care to the few tips I gave you: those are small things, but they help creating perfect packages ;-) Corrado
Re: [aur-general] Inclusion of ChangeLog Files
On Tue, May 6, 2008 at 10:11 AM, DaNiMoTh <[EMAIL PROTECTED]> wrote: > Are TUs that don't use often this feature :) I have detailed changelogs in almost all of my community packages. I don't use them in unsupported, however :-D Corrado
Re: [aur-general] TU Vote - Dragonlord
YES
Re: [aur-general] [arch-dev-public] abs tree checker
Sorry, tried to send this @ arch-dev-public. On Tue, May 27, 2008 at 10:44 PM, bardo <[EMAIL PROTECTED]> wrote: > On Tue, May 27, 2008 at 1:00 AM, Xavier <[EMAIL PROTECTED]> wrote: >> I think this script is something that packagers (of the official repos) >> should check regularly to ensure the quality of arch pkgbuilds and packages. > > Great work, thanks for the heads up. Now to my packages. > >> eclipse-ve --> 'eclipse<3.3' > > There's nothing I can do here: the latest visual editor doesn't work > with Europa. They say they're working on it. They've been saying this > for many months. > >> acerhk --> 'kernel26<2.6.25' > > Fixed this morning before seeing this e-mail ;-) > > > Corrado
[aur-general] TU reminder: set PACKAGER variable in makepkg.conf
(This is also valid for some devs.) Please, remember to set the PACKAGER variable in all your build machines. It really helps being able to know who built a package through pacman -Qi or -Si. Thanks, Corrado
[aur-general] sancho-gtk removal from [community]: discussion thread
Hi fellow TUs, devs and archers! I'm writing this long e-mail to discuss the current situation about sancho-gtk, a [community] package I'm maintaining. I inherited sancho-gtk, a front-end for mldonkey, when mOLOk resigned from his TU position, and some time ago I checked if everything was ok with it. In the PKGBUILD I found an ugly hack to download the software, which is hosted on Sourceforge but isn't available at the traditional download location. It is rather distributed through a direct link in its homepage (http://sancho-gui.sourceforge.net/), but that link changes every few minutes: because of this came the ugly hack. The whole thing, I discovered, was done on purpose by its author, whom I contacted for explainations. He pointed out that the download page page states "no redist/pkging/mirrors pls". I don't like forwarding private e-mails, so here's a summary of what I found out and some of my assumptions. * The author doesn't like his software to be repackaged because he doesn't want users complaining upstream for distribution-level bugs. * He doesn't really care if his user base drops to near-zero because his software isn't easily available and integrated in linux distributions. * I wasn't able to find the application's source code (the GTK version, at least) on his site, so I assume it is a closed source app. When the author was asked to clarify his position, include a license and, in case of a free one, the corresponding source code, he didn't answer. * The author thinks software inclusion in a linux distro is "opt-in" (his words), and states he never asked for it. When I pointed out that free software has nothing to do with opt-in, he stopped answering my e-mails. * The author never clearly stated (even though I asked) if we are infringing any license by redistributing the software. * An important phrase I think i just have to report is "I don't think a license has ever written any software", referring to his preference of distributing his software only through the homepage. I want to drop this software from our repos. Not because he asked for it, but because it looks like this person doesn't really understand what free software and a community are, and that we are persons, too, with our rights. He's not the kind of person I want to deal with. I also think he is in violation of Sourceforge terms, since he's maintaining what looks like proprietary software on their servers. What do you think about the whole thing? I already decided to drop both sancho-gtk and mldonkey (its development seems to be stalled), but there are more questions. Should I notify him to Sourceforge in case he is infringing? Should I drop the package to [unsupported]? Should I delete it? Should I hand it to another maintainer? I wouldn't want to see another ion3, but I don't think it's very different. Should we try to define special policies for cases like these? Corrado
Re: [aur-general] Integrity Check i686
On Fri, Jul 18, 2008 at 7:58 AM, Allan McRae <[EMAIL PROTECTED]> wrote: > eclipse-ve --> 'eclipse<3.3' There's nothing I can do about this. The VE doesn't work with 3.3 and we're still waiting for a release which was promised in October last year. Anyway, it's a widely used package, so I'm a bit reluctant in dropping it. Corrado
Re: [aur-general] [arch-dev-public] Please stop the install message insanity
On Mon, Jul 21, 2008 at 11:23 PM, Paul Mattal <[EMAIL PROTECTED]> wrote: > Thanks for pointing that out. I changed this to a post_install in dnsmasq > 2.43-2, not post_upgrade, since this one you have to read the first time and > not thereafter. This is a problem I've been thinking about for a while. It happens far too often that a message needs to be shown to the user only the first time a package gets upgraded because something important has changed. Without the need to modify anything we could use the parameters passed to post_upgrade: if the old version is affected by the change (can we use anything like vercmp in install files?) then the message will be shown, otherwise it won't. It's an extra effort on our side, but it helps a lot in cleaning up package installation output. Of course we'll also need to pay attention to when it's time to remove the message. I have other possible solutions in mind, but they all require changes to pacman or arch, and by far they aren't KISS. Any additional proposal or comment? Corrado
[aur-general] Semi-inactivity
Hi all! Two days ago I had my last exam for the semester and promptly got on a train for a deserved (?) vacation. I have some connectivity to check how things are going and if there are any problems with my packages (in fact I'm planning to update everything I left behind because of these exams) but you never know. So if any TU or dev feels the need to tinker with my things, then just do it. Well, if you can wait a bit just drop an e-mail =) I'll be back on July, 1st. Have a great time while you impatiently wait for me ;-) Corrado
Re: [aur-general] Semi-inactivity
On Wed, Jul 23, 2008 at 3:26 PM, bardo <[EMAIL PROTECTED]> wrote: > I'll be back on July, 1st. Heh. Obviously it's not a year-long vacation. I meant August, 1st. C.
[aur-general] UID/GID reservation request for pulseaudio
I hope this is the right ML for asking this... another mail will follow with a similar request for vlock. I'm pulseaudio's maintainer in [community]. This package needs one user (pulse) and three groups (pulse, pulse-access, realtime) to work, but I couldn't find suggested ids for them. I didn't change the values I found when I inherited the package, so at the moment we have id 130 for pulse user and group and 131 for pulse-access. The 'realtime' group was added only recently, replacing the old pulse-rt, which had 132, and doesn't have any assigned gid, which is *bad*. It would be good to officially reserve a few ids for this package (130, 131 and 132, maybe?), also considering this package should someday go to extra... Corrado
[aur-general] GID reservation request for vlock
Since the last few versions vlock requires a 'vlock' group, or another group that it is configured to use at build time. Vlock is a security program, so it would be better for it to have its own group, but I could also use an existing one, if someone can share a suggestion. Corrado
Re: [aur-general] TU Vote: Daenyth
On Mon, Aug 11, 2008 at 2:16 AM, Geoffroy Carrier <[EMAIL PROTECTED]> wrote: > Else, why > you think "no" is a better vote should be explained, because it might > means that you have something interesting to say! And this should be done during the discussion period. We already discussed the matter last year, IIRC. (Actually, I was the one who voted no and explained why only during the voting period... even though the candidate didn't pass, my action wan't exactly appreciated.) Corrado
Re: [aur-general] TU Vote: Daenyth
On Mon, Aug 11, 2008 at 5:20 AM, Ángel Velásquez <[EMAIL PROTECTED]> wrote: > I think that everyone is free to vote anything, and i don't know if bardo > (or anyother) will resign because now Daenyth is a TU (that will be childish > in fact), Don't worry, I don't plan to resign for something like this :) I just wanted to point out what already happened *to me*. In fact my opinion is: if it's something important, then you should write about it whenever you want, especially if the candidate doesn't seem to be prepared to fit the role. > the point is, that he reached a quorum, he now is a TU, and > welcome to the team, honestly i just hope that Daenyth will do a good work, > no matter what others (including me, yes i voted against Daenyth) can think. I'm totally with you about this, and having seen Daenyth's work a few times before his application, I think (and hope) he'll be able to do a good work. Thread closed for me :-) bardo
Re: [aur-general] UID/GID reservation request for pulseaudio
On Mon, Aug 4, 2008 at 2:47 PM, bardo <[EMAIL PROTECTED]> wrote: > I hope this is the right ML for asking this... another mail will > follow with a similar request for vlock. So, after almost two weeks, I have to suppose this isn't the right place. Where/who should I ask? Who's in charge of this? Maybe some dev can forward this mail (and the vlock one) to arch-dev-public? > I'm pulseaudio's maintainer in [community]. This package needs one > user (pulse) and three groups (pulse, pulse-access, realtime) to work, > but I couldn't find suggested ids for them. I didn't change the values > I found when I inherited the package, so at the moment we have id 130 > for pulse user and group and 131 for pulse-access. The 'realtime' > group was added only recently, replacing the old pulse-rt, which had > 132, and doesn't have any assigned gid, which is *bad*. Small correction: realtime has to be removed in favour of pulse-rt, and this should be final. > It would be good to officially reserve a few ids for this package > (130, 131 and 132, maybe?), also considering this package should > someday go to extra... About this last point, I think it was discussed a few times, and if I remember correctly Jan was the one who should have taken ownership to replace esd... will it happen anytime soon? Thanks, Corrado
Re: [aur-general] TU Application
On Fri, Sep 12, 2008 at 6:22 AM, Paulo Matias <[EMAIL PROTECTED]> wrote: > Besides that, I really want to bring Open Sound System related packages to > [community]. It's kinda a priority, as some users are eager for that. I gave OSS a shot, since it's free again and it seems to be technically superior to ALSA in many ways, but I noticed it is "a bit" aggressive with ALSA itself... to be clear: it killed my alsa modules. All of them. I had to reinstall the kernel to get it fixed. It's obvious that a package conflicting with kernel26 is less than ideal. I don't know if there's a way to prevent this behaviour, I got too upset to check and abandoned the whole thing. Do you know if the problem still exists? If yes, how do you plan to solve it? Thanks, Corrado
Re: [aur-general] TU Application
On Fri, Sep 12, 2008 at 7:22 PM, Paulo Matias <[EMAIL PROTECTED]> wrote: > If the user wants ALSA back, she only needs to remove the OSS package. So this means that the two systems can't coexist... I can't say I like it (I may prefer to use a particular sound system for a certain feature the other one misses) but at the moment I don't think there are other solutions. > In the install script (take a look at > http://aur.archlinux.org/packages/oss-testing/oss-testing/oss.install), We'll have to talk about that file (maybe in private, I'm hijacking the thread and it isn't nice), in particular about the removal of libflashsupport, which is also provided in libflashsupport-pulse, a package I've been wanting to move to [community] for a while. > No users had complained about problems restoring ALSA, so I think this > problem was present only in old packages, packaged by past > maintainers. Yeah, I got it with oss-linux-free, IIRC. Anyway, I *personally* think that no package should touch files owned by other packages, even though it seems harmless and reversible. I'd like to hear from others about this, though. Corrado
Re: [aur-general] Stopping Arch contribuiting
On Tue, Sep 16, 2008 at 12:35 PM, DaNiMoTh <[EMAIL PROTECTED]> wrote: > It's with a lot of sadness that I say "bye!" to archlinux. Thanks for all your great work... maybe I'll see you around at some random event around Italy =) Good luck with your life. Corrado
Re: [aur-general] Stopping Arch contribuiting
On Thu, Sep 18, 2008 at 11:45 AM, Alessio Bolognino <[EMAIL PROTECTED]> wrote: > While on topic, is anybody going to ESC[1] ? > 19-21 September, San Donà di Piave (Venice) I am. I'll see you tomorrow evening, then :-) C.
Re: [aur-general] TU Vote: Kessia 'even' Pinheiro
On Mon, Sep 22, 2008 at 10:25 PM, Anders Bergh <[EMAIL PROTECTED]> wrote: >> ps. we'll dominate the world! =D > > I, for one, welcome our new Brazilian TU overlords There, fixed it for you ;) There was a time when Italians tried to take over Arch, but then many brave and strong TUs were forced to quit because of the evil forces of Real Life. But it is said that Italians will rise up again, and take over the Intertubes by the means of Arch. Beware us! MWAHAHAHAHAHAHA (ok... all this bull to say... welcome aboard, Kessia :) bardo
Re: [aur-general] Orphans in community part II
On Tue, Oct 7, 2008 at 8:18 PM, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > eclipse-mylyn 3.0.0-1is already outdated (3.0.2 is out), two Oh my... this is mine! It has just been introduced as a dependency for eclipse-subclipse and newer versions don't work with it, so I won't update it. I'm adopting it now... it's been so long since I added a new package that I forgot I had to adopt them afterwards =P Corrado
Re: [aur-general] TU Application
On Thu, Oct 9, 2008 at 6:28 PM, Xavier <[EMAIL PROTECTED]> wrote: > This line is controversial for the following simple reasons : > [...] You're right it's controversial. If I understood correctly the large majority of devs/TUs is made by vim users, so this could be a reason to leave it in. I'll be happy to ditch it in any case, though, if some vim guru explained (and meybe wikified) how to get the same result with your .vimrc or whatever way it's done. After all, those who don't like it will continue to remove it, and those who like it will continue to use it in their rc file. Corrado
Re: [aur-general] namcap reports
On Tue, Oct 14, 2008 at 4:11 PM, Aaron Griffin <[EMAIL PROTECTED]> wrote: > I'm with Callan and Xavier here - this is awesome. Sure! Now, if only it could be possible to filter by maintainer...
Re: [aur-general] TU Inactivity angvp
On Thu, Oct 30, 2008 at 3:27 PM, Angel Velásquez <[EMAIL PROTECTED]> wrote: > Well the time runs fast!, good, I have more time now, i am not free at > all but i can say that i am Active again! Great, welcome back! :-) > FYI, I will be traveling to Europe (Spain,Italy) from November 17 > until Jan 15, I will have internet connection in the most of the > places that I will be, so I think is not necessary to flag me as > Inactive again ;) Well, if you'll be in Milano or nearby just drop me an e-mail and we'll have a beer or something together! Lots of archers here ;-) I'm really busy but maybe I'll find some time... Corrado
Re: [aur-general] CVS problem?
On Tue, Nov 11, 2008 at 4:43 PM, Abhishek Dasgupta <[EMAIL PROTECTED]> wrote: > While trying to commit to CVS at 1541 UTC, I got this error: > > cvs [login aborted]: connect to cvs.archlinux.org(66.211.213.17):2401 > failed: Connection refused Confirmed here and by some TUs in irc. Let's wait for a fix =P Corrado
[aur-general] Eclipse plugin packaging standardization proposal
Hi all. Maintaining a few Eclipse plugins in [community] I stumbled in a lot of difficulties while packaging them. I then decided to create a PKGBUILD prototype for these package and propose it as a packaging standard. I'd like to have some input from the community, TUs and devs about this. If the response is positive I'll wikify the whole thing and make it available to everyone. You can find the prototype here[1], along with the explanation of how it works and why. Thanks, Corrado [1] http://blog.bardland.org/2008/11/20/arch-linux-eclipse-plug-in-packaging-a-proposal/
Re: [aur-general] Eclipse plugin packaging standardization proposal
On Thu, Nov 20, 2008 at 3:04 PM, solsTiCe d'Hiver <[EMAIL PROTECTED]> wrote: > hi. Hi, and thanks for answering :) > (1) > why have you dropped the following syntax ${feature%*.jar} in favor of > ${feature/.jar} ? > > it was like that in the source PKGBUILD from Jonathan Wiersma that i > showed you at http://aur.archlinux.org/packages.php?ID=19476 If there's a difference between the two, then I don't know it. I just sticked to the syntax I currently use in all of my scripts, which by the way, if the two are equivalent, looks clearer to me. I've been exchanging e-mails with Jonathan for quite some time, now. Yesterday I sent him the link to my blog and he still hasn't said anything... I'm still waiting for his critics. If he has some to make, that is :) > you could also use ${pkgname/#eclipse-} Same question: is this better in some way? What's the real difference? > (2) you could use the jar command to extract a jar file instead of > unzip. that's what it's made for. it's in the jdk which is a dependancy > of eclipse. so you can expect user to have jar command and jdk package > (jar is also in java-gcj-compat) This is a great idea, I'll look into it. > what kind of error do you get with bsdtar when extracting a jar ? and > how (with which command ?) ? i got none with the only jar i tried to > extract with bsdtar -xf somejar.jar Same command (only with -C switch, but that makes no difference). I got a lot of "Write request too large", same thing that happened here: http://aur.archlinux.org/packages.php?ID=15746 (and somewhere else, but it's not very common, so I found no solution). > and by the way, i don't understand you at all > in bug #12163, you say eclipse-mylyn is a dep of eclipse-subclipse. but > now i see that eclispe-subclipse does not depend anymore on > eclispe-mylyn !? That was when I didn't really understand how the eclipse plugin system worked :) Subclipse provided its own version of mylyn, but its features were jarred, so they weren't detected. At the time I solved removing mylyn's jars from subclipse and adding eclipse-mylyn as a dependency. That didn't work very well because I couldn't update mylyn to the latest release. The problem is now solved. Corrado
Re: [aur-general] Eclipse plugin packaging standardization proposal
First of all, nobody really wrote /against/ this proposal and nobody said there's no need for a standard, so I suppose everyone's ok with it. If this is not the case, just speak up, otherwise I'll wait for a week from the last comment and then proceed to wikify it. On Thu, Nov 20, 2008 at 5:37 PM, Aaron Griffin <[EMAIL PROTECTED]> wrote: > / syntax is actually for replacement. The syntax above says "replace > with nothing". The # and % syntax is for deletion (matching from the > front or back of the word, respectively). I doubt there's any real > difference as far as performance goes. I'll keep the slash syntax, then, it's also simpler to customize. Thanks fo the great explanation :) >> (2) you could use the jar command to extract a jar file instead of >> unzip. that's what it's made for. it's in the jdk which is a dependancy >> of eclipse. so you can expect user to have jar command and jdk package >> (jar is also in java-gcj-compat) I modified the PKGBUILD to use jar instead of unzip, thanks. However I had to do some other changes. As I pointed out in the post: «I was noticed that I can directly use jar, which the user already has since it's part of the JRE. This is great, since it spares a makedepend! However, jar can't extract to directories other than the current one: this means that, after the directory creation, it's necessary to cd before extracting. Since there were many occurrences of the destination path I decided to use a custom variable even though somebody might not like it, because there's a great improvement in readability.» Quick link reference: http://blog.bardland.org/2008/11/20/arch-linux-eclipse-plug-in-packaging-a-proposal/ Corrado
Re: [aur-general] huge differencies between i686 and x86_64 community repo
On Sun, Nov 30, 2008 at 12:38 PM, Jaroslav Lichtblau <[EMAIL PROTECTED]> wrote: > A quick look on the nice page showing differencies between our i686 > and x86_64 repos [1], shows a pretty impresive list in our [community] > repository. Could we please work on this a bit and keep it > synchronised! I'll hopefully invest some money briefly and get a new laptop... then I'll be able to help with x86_64 :) Corrado
Re: [aur-general] TU Meeting
On Mon, Dec 1, 2008 at 2:20 AM, Allan McRae <[EMAIL PROTECTED]> wrote: > - bardo drunk too much wine and was having difficulty spelling. You could have left out this point ;-) But you know... wine is for intellectuals... maybe. > A bit more detailed summary: > - There was some agreement that there appears to be a lot of packages with > low usage in [community] > - There was lots of disagreement about the validity various popularity > measures (pkgstats, AUR votes). > - No better method for assessing popularity was proposed > - Restricting entry to [community] based on "popular usage" was discussed > - A few do not like the idea of restricting TUs packages > - The definitions of "popular" are hotly debated > - A proposal for new rules for packages entering [community] will be posted > to the aur-general list for more discussion > - A separate proposal about removing low usage packages from [community] > will be made at a later date. All the previous points can be summarized in few words: "we agree that we disagree". > - It was proposed to add a safe flag on TUs packages in the AUR to encourage > TUs to leave packages out of community while still being marked in a way as > they are known to be good PKGBUILDs I missed this part... luckily. Safe flags were happily killed with a few months ago. If you mean to add them to [community] packages only, then it doesn't make sense to me: to make a TU you don't just need the User, you also need the Trust. Either you don't T the U from the beginning (and s/he doesn't get elected) or you T, and then you don't need to flag anything. If someone notices an anomaly in a TU's PKGBUILD quality, it should readily be reported to the list to take action. > - Improving the community backend to reduce server load is being discussed. This is a very important point, IMHO, which we need to discuss with the AUR2 guys. In fact I think we could, as we say in Italian, "catch two pigeons with one broad bean" :) and plan the backend changes to include the move to SVN. Personally, I'd like to see an independent RCS layer so that we won't see this situation again when we need to move to $ZOMGCOOLRCS. Corrado
Re: [aur-general] community back-end rewrite
Heh. This happens when you don't read all of your e-mails before answering. So, here's a bit of copy 'n paste from my last message, and some new thoughts. On Mon, Dec 1, 2008 at 2:35 AM, Allan McRae <[EMAIL PROTECTED]> wrote: > In the TU meetings there was some discussion about doing a > rewrite/update/fix-up of the [community] back-end. I am not sure who all is > looking at this and what the plans are - hence this email. I think the only work done is in AUR2, but I don't know if they have touched the backend. Could any of the involved people update us on its status? > Can people who are looking at this or interested in looking at this give a > ping back to this message with whatever plans you have or work you have > already done. From my lst mail: «This is a very important point, IMHO, which we need to discuss with the AUR2 guys. In fact I think we could, as we say in Italian, "catch two pigeons with one broad bean" :) and plan the backend changes to include the move to SVN. Personally, I'd like to see an independent RCS layer so that we won't see this situation again when we need to move to $ZOMGCOOLRCS.» > Things I want to flag: > - we should get a git repo for a community-backend project on the arch > server and separate this from the aur site code. - we should switch SCM > tools from CVS. I am strongly in favour of using the same system as the > main repos which would allow much code reuse and easily get us a testing > repo for community packages. (No more big rebuild issues!). Here I agree with Loui: it doesn't make sense to separate the AUR and the [community] backend, they are tightly coupled and so they should be. The risk is to break things if two groups move independently. And I'm not really sure we could reuse some code, but writing an SCM abstraction layer that makes us independent from CVS and SVN could be userful for the main repos, too. I don't think it's a stupid idea because we just need the basic operations that every SCM provides... Corrado
Re: [aur-general] community back-end rewrite
On Mon, Dec 1, 2008 at 9:22 PM, Daenyth Blank <[EMAIL PROTECTED]> wrote: > On Mon, Dec 1, 2008 at 14:46, Aaron Griffin <[EMAIL PROTECTED]> wrote: >> Hmm, perhaps we could just set a rule such that any removal at all is >> copied to the unsupported dir, and then people could simply delete the >> package from the front-end. >> > That makes a lot of good sense. Seconded. Unless we want repos to be more hierarchical, were a removal from core goes to extra, from extra to community, from community to unsupported. Somewhat impractical, imho. An alternative could be the implementation of a "move" abstraction. Then moving packages from any repo to any other (unsupported included) could be really simple and straightforward. Corrado
Re: [aur-general] Proposed rules for packages entering [community]
On Thu, Dec 4, 2008 at 9:54 AM, Kristoffer Fossgård <[EMAIL PROTECTED]> wrote: > Your all missing my point. I never said counting packages by > downloadrate is a perfect solution but that IT IS GOOD ENOUGH _and_ > BETTER THAN THE VOTE SYSTEM. That's what I thought. Even monitoring a single download mirror could be enough, if it's not an obscure and unpopular one. At least gathered data would be statistically *relevant*, even though not accurate. We can think of a single mirror as a good approximation of the whole community, excluding i18n/l10n packages, which are highly dependendt on the physical location of the mirror itself. Corrado
Re: [aur-general] GPL compliance (was Re: Circle that A)
On Fri, Dec 5, 2008 at 1:32 AM, Callan Barrett <[EMAIL PROTECTED]> wrote: > But if the packages are popular surely they should be in community, > that's the point of this entire vote. I haven't seen it as putting a > limit on actual package size. Right. The games problem will be greatly mitigated when generic architecture packages will be fully supported. Corrado
Re: [aur-general] Official discussion period - Rules governing packages entering [community]
On Wed, Dec 3, 2008 at 12:39 AM, Allan McRae <[EMAIL PROTECTED]> wrote: > This starts the official discussion period for the addition of rules > governing the addition of packages to [community]. As this is essentially a > bylaw change, we will use that voting procedure: 5 days discussion, 7 days > voting, quorum of 75% required. Since this is an official discussion period, I'll state my opinions in a (hopefully!) brief form. I've been thinking about the whole thing for quite a while now, evaluating all opposing opinions, and I have made up my mind. Any reply is welcome. I *won't* let the discussion end up in a flame, so don't expect an answer to provocative e-mails. I have seen, on both sides of the fence, a lot of people falling in the quicksands of 'a priori' arguments. I'm trying to address the problem and the solutions I can think of from a rational point of view. My succinct conclusions: . Everybody agreed that we weren't able to find a statistically relevant way to calculate package usage. . Imposing limits, albeit relaxed, on TUs will, in my opinion, demotivate many of them. I'll be the first to feel demotivated. . We are using as a reference the pkgstats results that came from very few days of usage. If we really want to put arbitrary limits, then they should be discussed after *at least* one month of pkgstats running. I already wonder: did results change from when we started the discussion? . Even if we restrict package uploading in some way, this won't mean we'll have solved the resource problem: it will only be postponed. If we reduce package intake by 10% (aka: more than it was proposed) it will only take ~11% more time to hog the server resources again, supposing all packages have the same weight. It was demonstrated that the least used packages are pretty small, though. Not a real solution, imho. . With this vote we don't consider that we are *not* totally independent from Arch, even though we theorically are. As Aaron rightly stated, we also need to consider their opinion about the matter. A TU-only vote does exactly the opposite, until an official proposal comes from them. These are the reasons why I intend to REJECT the proposal. My (hopefully constructive) alternative proposals: . Ask someone who knows well what s/he's taking about (a statistician) if s/he can come up with a way to get better numbers from the means we have, with the constraints we have, then decide how to act. . Work with widely used third-party applications (aurvote, yaourt) to better exploit the mean of voting, and get more useful numbers. . Don't put any hard limits at all, just encourage contructive discussion and communication between TUs themselves, the community and devs. I personally trust all of you TUs and I think that, by better defining what our goals are and how we want our repo to be, we can solve this problem without much hassle. «Freedom is not the capacity to do whatever we please; freedom is the capacity to make intelligent choices.» -Frances Moore Lappé Corrado Primier
Re: [aur-general] Official discussion period - Rules governing packages entering [community]
2008/12/5 Callan Barrett <[EMAIL PROTECTED]>: > But why? Why make 2 definite sets of votes when it's just as easy to > bring this up again if it's not working out? This just seems like an > out for people who don't want this to happen, if you don't like it you > should vote no on it. I agree, let's see how this vote goes, then eventually decide for alternatives. I wrote my ideas not to ask to change the current proposal, but only to have people consider them as alternatives. I don't think it's right to criticize without at least trying to find viable alternatives. Corrado
[aur-general] VirtualBox and 64bit guests
Hi fellow TUs. I'm happy to inform you that the new VirtualBox 2.1.0 finally added support for 64bit guests on 32bit hosts. So if you always sticked to arch32 because of lack of proprietary apps/lack fo time/fear of "those new things"/whatever... now you have no more excuses =) You can start contributing to arch64 today, just install a virtual machine! I'm doing it myself now ;-) Cheers, bardo
Re: [aur-general] VirtualBox and 64bit guests
2008/12/18 Anders Bergh : > It only works if you have a quite recent CPU with 64-bit & > virtualization built-in. VMware however supports running 64-bit guests > on 32-bit AMD CPUs without VT-x/AMD-V. I think this is one of the next steps in the roadmap. Nevertheless, the virtualbox team is demonstrating with every release that big changes are going on, and that the project is quite active. I see them challenging vmware itself in a not so far future... Anyway this last version can be very useful to some of us; we'll see what the next ones will bring =) Corrado
Re: [aur-general] Removal of Bogus package.
2009/1/12 KalasMannen : > Can anyone help me remove a bogus package i accidentily uploaded to the AUR? > It's located at http://aur.archlinux.org/packages.php?ID=22825, and is > basiclly just an upload of the official kernel26 PKGBUILD from svn. Removed. Corrado
Re: [aur-general] PulseAudio doesn't work after update to 0.9.14
2009/1/22 Jeff Cook : > Heh, forget to append the output of pulseaudio --system -vvv: Hi Jeff, first thing I'd try, does pulseaudio work as a user? Stop the daemon and launch it with no arguments with your user, maybe it's some kind of permission problem. Also, is your user a member of pulseaudio's groups? They are pulse, pulse-access and pulse-rt. Corrado
Re: [aur-general] TU Resignation angvp
2009/2/16 Angel Velásquez : > Hi all again, Hi Angel. I'm sorry if I couldn't answer until now, but as you know I'm pretty busy =) I'm sad to see you go, but I'm also thankful because you left a great work behind you. If some day you'll want to join us again, you know we'll be happy to work with you! And by the way, if you drop by Italy again someday, just drop me an e-mail for a free beer ;) > Since I resigned I haven't see anybody interested on any of packages > that I maintained, (just python-numpy and python-nose but it will be > moved to community it wasn't an adoption at all). Damn... I'm having a hard time maintaining all of my packages, I think I'm full. Anyway, if nobody takes over splix, I'll make an extra effort and take it, since I do use it myself. Corrado
Re: [aur-general] Mutt vs Gmail (Was: An idea for vim scripts/plugins)
2009/5/11 Ricardo Martins : > I also found that I could read all new emails much faster in mutt than > in gmail -- I just TAB my way around in each label/directory instead > of clicking and scrolling. My muscle/finger memory makes me more > efficient at using mutt than the web interface, that's all. Did you try enabling gmail's keyboard shortcuts? They've done a fairly good work on those ones. The only case where I don't suggest to use them is if you enabled find-as-you-type in your browser, which basically breaks shortcuts for *any* site. Also, sometimes (rarely, TBH) the actual browsing area "loses focus", so you have to click inside (or press tab) before you can use shortcuts again, but that's a minor annoyance for me.
[aur-general] Inactivity - 21st-25th May
Hi guys, This afternoon I'm leaving for a short holiday in Bratislava and Vienna, I'll be back on Monday. I probably won't have Internet access during this period, so feel free to update my packages. Not that I've been very active lately, but well, I'm reading my mails =) I also catch the occasion to ask if some x86_64 TU can rebuild rss-glx, since the latest version keeps segfaulting on me but it seems to be ok on other machines. The i686 package is already in place. If someone does, please close FS#14285. Thanks, Corrado
Re: [aur-general] Inactivity - 21st-25th May
Found an Internet point =P 2009/5/21 Xyne : > I've just tried building rss-glx on x86_64 and received a segfault as well. Ah, great. I just reported what djgera wrote in the mentioned bug report (he also attached a successful build log). > Anyway, enjoy your holiday! Thanks, that's exactly what I am doing =D Corrado
Re: [aur-general] Removing comments from AUR
> On Wed, Jun 24, 2009 at 17:03, Grigorios Bouzakis wrote: >> May i suggest something slightly relevant, but probably very radical? >> Disable comments on AUR completely. I don't understand why this was even proposed. It seems rather obvious to me that this is not a wise idea: how is a package maintainer to know if someone opened a thread on his package on the bbs? Does every maintainer get his own personal forum? Same goes for the ml: imagine the whole AUR comments becoming e-mails... it would be chaotic to say the least. Forums and mailing lists are general-purpose instruments, and for this very nature they can't be very structured. They are also open to abuse. The AUR has a specialized function, and it does it well. Why split it into two? Keep the information where it belongs (on the package page) and keep a clean structure (don't put everything in one place without easy ways to filter). Where's the KISS philosophy? This is a BIG -1 from me. Corrado
Re: [aur-general] Removing comments from AUR
2009/6/25 Xavier : > Having the information on the package page is indeed very practical. > > I guess the problem is that there is absolutely no organization and > structure of that information. No way to group messages by problems, > to easily see which points are still open / relevant, etc. If you intend to propose a bug tracker for the AUR, I think this is overkill :) I think it's good this way... even though it could be improved. Threaded comments? Requests for comment deletion to the package owner? This is what comes to the top of my mind. Corrado
Re: [aur-general] AUR Moving
2009/6/28 Xyne : > After a bit of ssh wiki'ing I can confirm that everything seems to be > working here. I've added a link to the "Using SSH Keys" page on the > "AUR Trusted User Guidelines" page, with a specific mention of the > ssh-agent in case anyone else is new to using ssh keys for remote > logins. Confirmed ssh works, just like cvs checkout and commit. Well, at least they seem to. I uploaded three packages (eclipse-{emf,gef,mylyn}) for x86_64 with communitypkg some time ago, but the only confirmation I got is that running 'cvs update' checks out my latest changes. I can't find evidence of updates, not in AUR, nor in mirror sync, nor in repos.archlinux.org. Provided I didn't wait very much (less than two hours) is there something that still needs to be configured for the new server or are the services ok? Do uploads already work as expected? And finally, has AUR<->[community] sync gone for good? Thanks, bardo
Re: [aur-general] AUR Moving
2009/6/29 Loui Chang : > Actually I just realised that it's a longstanding bug/feature that the > update script does not update the AUR database for x86_64 only packages. > So that's normal behaviour. i686 packages are being updated. The repo doesn't seem to be updated, though. I uploaded the packages about five hours ago, and my mirror has surely synced since then[0], but a -Sy never downloaded the [community] db... [0] http://archlinux.puzzle.ch/community/os/x86_64/lastsync
Re: [aur-general] communitypkg does not work
2009/7/1 Stefan Husmann : > I cannot upload packages to community. I have a ssh account and did set > CVS_RSH and CVSROOT. Yesterday it worked. I have no idea what is going wrong > here. I was about to post the same. Basically, ports 1034-1035 are closed on the server :) [ba...@forty-two ~]$ nmap -p 1034-1035 aur.archlinux.org Starting Nmap 4.76 ( http://nmap.org ) at 2009-07-01 11:52 CEST Interesting ports on client-208-92-232-29.sevenl.net (208.92.232.29): PORT STATE SERVICE 1034/tcp closed unknown 1035/tcp closed unknown Nmap done: 1 IP address (1 host up) scanned in 1.70 seconds
Re: [aur-general] communitypkg does not work
2009/7/1 Sergej Pupykin : > btw, > > [spupy...@sigurd ~]$ netstat -tlnp Right... I keep forgetting I now have a shell account =)
Re: [aur-general] TU: Password Reset
2009/7/6 Dieter Plaetinck : > Surely you can. use e-mail to lock a mutex. That's the "volleyball technique". The first that shouts "MINE!!!" gets the ball ;)
Re: [aur-general] Disowning monsoon, monotorrent and mono-nat
2009/7/6 Angel Velásquez : >> I'm not really sure where you're gathering your rules from. >> If excess traffic on the list does become a problem, we'll find ways to >> solve it. > > Common sense, just let everybody believe that they have to report > anything on this list (as the childres ask the teachers for permission > to go to the bathroom) and you will get a nice flood, "mathematics > never fails", but go ahead, do what you want, you will remember me, > when you will get pissed off about this :) Please guys, calm down. Let's sit down a minute and think about it. Tomás brought to our attention a problem that all of us have noticed: there's no mean, for willing contributors, to find out if a package has been orphaned. I think Angel is right with this ML not being the right place to signal orphan packages, since there's usually no discussion involved. On the other hand, I feel that he expressed his ideas in a bit too strong way. Anyway, back to the problem. I see two (non-mutually exclusive) possible solutions: 1. Add a notification e-mail for package orphaning. In fact, orphaning is a very important phase in the package life, and between package subscribers there will probably be at least one person who wants to step up and adopt it. I'm all for this one. 2. Add an "orphaning RSS feed". Many willing contributors are always looking for nice packages to maintain, and they have no way to find out if their favorite package has been orphaned. An RSS feed would allow contributors to quickly substitute former maintainers, thus allowing an overall better AUR quality. What do you think? Corrado
Re: [aur-general] Disowning monsoon, monotorrent and mono-nat
2009/7/6 Angel Velásquez : > The first solution seems better to me (but both solutions can be > implemented), why the first solution is better to me?, Well in the > case when a guy with several packages decided to orphan all his > packages the users who have an rss client pointing to the "orphan rss" > will get flooded heh.. but it's the risk that they took in any case. You're probably right... not because of flooding, though, but because of RSS limits: if the RSS feeds shows 20 packages and somebody orphans 30, 10 will invariably be "lost", and it defeats the purpose. Anyway, if someone follows an RSS feed, s/he should be prepared to see a lot of entries. After all, it can't be bigger than the new package feed we already have. If it is, we have a problem, and it's not the one we thought it was =) Or is it possible to give an RSS a "time limit", which shows entries for the last X days regardless from the number? Anyway, I'm still for both, strongly for the first one, a little less on the second one, but I still think it's valid. Corrado
Re: [aur-general] Application for TU
2009/7/7 corvolino : > Hi all. > > I'd like to thank you for all your suggestions. Some mails made me open my > eyes, then I perceived that this is not the right moment for becoming a TU. > I'm sorry for any inconvenience. I hope to study more, prepare more, to soon > come and apply again for TU. This is a great attitude you have, I really like it! Too bad not many people appreciate constructive criticism. I hope you'll work on your skills and come back, 'cause I think we really need someone like you in our team =) Corrado
Re: [aur-general] introduction and questions
2009/7/7 jezra : > depends=('gstreamer0.10-base' 'ncurses' 'vala>=0.7.2') Shouldn't 'vala' be in the makedepends array? It's just a compiler, it isn't needed to run the binary, right?
[aur-general] AVR toolchain update
I've been delaying this update for quite a while. At the moment I've got a working binutils-avr, and I'm trying to make gcc work. I'm still not on the 4.4 train, which IIRC introduced the gcc-libs package. I have to admit that the gcc-libs role is not really clear to me, and I'm not sure I need an AVR-compiled version, but my gcc-avr build still fails and I don't know why, so I have no way to check. Can someone who knows more than me shed some light on this? Thanks, Corrado
Re: [aur-general] [arch-dev-public] Inactive
2009/7/9 Roman Kyrylych : > I've been to Amsterdam this Spring for few days, and it's definetely a > nice place. Speaking of which... will anyone be at HAR (Hacking at Random) near Amsterdam this summer? I will! :) Corrado 'yay for thread hijacking' Primier
Re: [aur-general] AVR toolchain update
2009/7/9 Allan McRae : > You do not need a gcc-libs-avr as the whole puropse of you package is to > privide the compiler. gcc-libs was split so people did not need the > compiler on their system. Great, that's what i suspected but I wasn't sure. > If you post some details about the build failure you are having, I may be > able to help. The build fails (in a clean chroot) on libgcc's configure: - Checking multilib configuration for libgcc... mkdir -p -- avr/libgcc Configuring in avr/libgcc configure: creating cache ./config.cache checking for --enable-version-specific-runtime-libs... no checking for a BSD-compatible install... /bin/install -c checking for gawk... gawk checking build system type... i686-pc-linux-gnu checking host system type... avr-unknown-none checking for avr-ar... avr-ar checking for avr-lipo... avr-lipo checking for avr-nm... /build/src/gcc-4.4.0/build/./gcc/nm checking for avr-ranlib... avr-ranlib checking for avr-strip... avr-strip checking whether ln -s works... yes checking for avr-gcc... /build/src/gcc-4.4.0/build/./gcc/xgcc -B/build/src/gcc-4.4.0/build/./gcc/ -B/usr/avr/bin/ -B/usr/avr/lib/ -isystem /usr/avr/include -isystem /usr/avr/sys-include checking for suffix of object files... configure: error: in `/build/src/gcc-4.4.0/build/avr/libgcc': configure: error: cannot compute suffix of object files: cannot compile See `config.log' for more details. make[1]: *** [configure-target-libgcc] Error 1 make[1]: Leaving directory `/build/src/gcc-4.4.0/build' make: *** [all] Error 2 ==> ERROR: Build Failed. - Here's the config.log: http://pastebin.com/m2c4de4d2 Here's my gcc-avr PKGBUILD: http://pastebin.com/m7ed5e45c Here's binutils-avr build files: http://www.bardland.org/files/binutils-avr-2.19.1-1.src.tar.gz The build is successful outside makepkg, and the problem seems to be path-related. Thanks for any help, Corrado
Re: [aur-general] AVR toolchain update
2009/7/11 taptaptap dödödö : > Hello bardo! > > I've spent more time with it too! > The problem is, it tries to build with that C(XX)FLAGS, which is in your > /etc/makepkg.conf! > It can be a hack, but works for me. Set the CXXFLAGS="" && CFLAGS="" for the > building session, and can be built well. Thanks, as we discussed in private the toolchain has now been updated, even though I've been notified by various sources that it is broken for some AVR architectures. Since I haven't been able to solve the problem quickly, I'm asking for some help on the list. So, here's an explanation of what I found out until now. What's happening: avr-ld, for some reason, doesn't descend into /usr/avr/lib/ subdirectories while searching for object files, so it doesn't find arch-specific linker files. I've found an old bug report that oulines the same problem, even though with no solution posted: http://savannah.nongnu.org/bugs/?22539 A (temporary and very ugly) workaround, for those who work with only one architecture, is linking files in, for example, /usr/avr/lib/avr4/ to /usr/avr/lib/, paying attention to backup files by the same name (libm.a, libc.a...). In the meantime I'm trying hard to solve the issue, but I can't really find where the problem lies, so if anybody has any knowledge of toolchain-building and has suggestions to share, please write :) Thanks, Corrado
Re: [aur-general] AVR toolchain update
2009/7/17 taptaptap dödödö : > Hello Bardo! > > I will look at this at evening, after my work :) > Hope i can help you. Thanks, I hope you can help me too ;)
Re: [aur-general] AVR toolchain update
2009/7/17 bardo : > A (temporary and very ugly) workaround, for those who work with only > one architecture, is linking files in, for example, /usr/avr/lib/avr4/ > to /usr/avr/lib/, paying attention to backup files by the same name > (libm.a, libc.a...). Ingo Becker notified me of a much better workaround: add -B/usr/avr/lib/yourarch to the gcc command line. For example: $ avr-gcc -mcpu=atmega8 -O2 -Wall -B/usr/avr/lib/avr4 source.c
Re: [aur-general] AVR toolchain update
2009/7/17 taptaptap dödödö : > Well, is it okay or shall i see at evening ? Unless it's a new gcc "feature", which I highly doubt, no, it's not ok, it's just a workaround =)
Re: [aur-general] AVR toolchain update
2009/7/17 taptaptap dödödö : > Bardo! > > First of all, you didn't add this file to the CVS, i can't test it. > > binutils-2.19-as-needed.patch I should have done it... CVS isn't updating anymore, we've benn moved to a shiny new svn ;) Anyway, it's the same patch in the offical binutils, so you can find it in /var/abs/core/binutils/ :)Anyway utils/ :)Anyway
Re: [aur-general] AVR toolchain update
2009/7/17 bardo : > 2009/7/17 taptaptap dödödö : >> Bardo! >> >> First of all, you didn't add this file to the CVS, i can't test it. >> >> binutils-2.19-as-needed.patch > > I should have done it... CVS isn't updating anymore, we've benn moved > to a shiny new svn ;) Anyway, it's the same patch in the offical > binutils, so you can find it in /var/abs/core/binutils/ :)Anyway > utils/ :)Anyway I think I got it! A user named pullmoll wrote a very useful comment in gcc-avr's AUR page. It didn't like the --disable-multilib flag, which purpose I had evidently mistaken and is clear to me now... that was the meaning of multiple architecture support ;) I'm uploading gcc-avr-4.4.0-2 now for x86_64, i686 will follow shortly. Thanks everybody for the help! Corrado
Re: [aur-general] CVS freeze and move to SVN/official tools
2009/7/17 Aaron Griffin : > Adding Id tags to svn now I got pwned by this one. My svn-fu is very weak, so I'm a bit stuck. I was updating a package right when you did this, so here's what I did (sorry for the Italian text, I hope it's self-explanatory): [ba...@forty-two trunk]$ svn commit Trasmetto trunk/ChangeLog Trasmetto trunk/PKGBUILD Trasmissione dati ..svn: Commit fallito (seguono dettagli): svn: File '/gcc-avr/trunk/PKGBUILD' is out of date svn: Il tuo messaggio di log è stato salvato in un file temporaneo: svn:'/home/bardo/tu/svn-packages/gcc-avr/svn-commit.tmp' [ba...@forty-two trunk]$ svn up GU PKGBUILD Aggiornato alla revisione 82. [ba...@forty-two trunk]$ svn commit -F ../svn-commit.tmp Trasmetto trunk/ChangeLog Trasmetto trunk/PKGBUILD Trasmissione dati .. Commit della Revisione 83 eseguito. [ba...@forty-two trunk]$ archrelease community-x86_64 property 'svnmerge-integrated' deleted from '../repos/community-x86_64'. --- Merging r82 through r83 into '../repos/community-x86_64': UU ../repos/community-x86_64/PKGBUILD U../repos/community-x86_64/ChangeLog property 'svnmerge-integrated' set on '../repos/community-x86_64' ~/tu/svn-packages/gcc-avr ~/tu/svn-packages/gcc-avr/trunk Trasmetto gcc-avr/repos/community-x86_64 Trasmetto gcc-avr/repos/community-x86_64/ChangeLog Trasmetto gcc-avr/repos/community-x86_64/PKGBUILD Trasmissione dati ..svn: Commit fallito (seguono dettagli): svn: Directory '/gcc-avr/repos/community-x86_64' is out of date *** ATTENTION: There was a problem merging the package changes *** To fix it, edit the conflicting files in repos/community-x86_64 (the ones that are C in svn status). Once you have resolved conflicts, execute 'svn resolved ' to tell svn the error was resolved. Then to finish the merge commit, execute 'svn commit -F trunk/svnmerge-commit-message.txt' and, if there are no problems, delete trunk/svnmerge-commit-message.txt [ba...@forty-two trunk]$ ls ChangeLog PKGBUILD gcc-avr-4.4.0-2-x86_64.pkg.tar.gz svnmerge-commit-message.txt [ba...@forty-two trunk]$ And here's where I got stuck... how do I check svn statuses and conflicts?
Re: [aur-general] CVS freeze and move to SVN/official tools
2009/7/18 bardo : > *** ATTENTION: There was a problem merging the package changes *** > To fix it, edit the conflicting files in repos/community-x86_64 (the > ones that are C in svn status). > Once you have resolved conflicts, execute 'svn resolved file>' to tell svn the error was resolved. It seems it was lying. No .mine files in the whole tree. I just had a 'svn up' in the root gcc-avr dir (*not* in trunk), checked nothing was changed, went back into trunk, ran 'svn commit' and finally ran 'archrelease community-x86_64', which yielded a "nothing to commit". I don't quite grok it, but it seems to be fine. Sorry for the noise. C.
[aur-general] Inactivity
Hi guys, tomorrow I'm leaving for a summer vacation, and I'll be back on August, 1st. Feel free to update my packages, it'd just be kind to drop me a note if you do, but I'll probably notice anyway :) Corrado
Re: [aur-general] Inactivity
2009/7/21 bardo : > Hi guys, > tomorrow I'm leaving for a summer vacation, and I'll be back on > August, 1st. Feel free to update my packages, it'd just be kind to > drop me a note if you do, but I'll probably notice anyway :) I'm back! Though I have some problems on my right hand and writing is really painful at the moment. Sorry if I'll be a bit silent in the next period, I'm here, though. C.
Re: [aur-general] Inactivity
2009/8/1 Xyne : > Welcome back! Thanks to all for the warm welcome back! :D > Did you have a good time? What happened to your hand? I had a *really* good time. It wasn't a real vacation, it was a music class. It's the first time I do something like this (which involves playing many, many hours a day) with my new tenor saxophone, which is much heavier on the hand than other instruments I play, so I got a nice thumb inflammation. Add a beginning of carpal tunnel syndrome and you can imagine how I feel like now -.- Hope to be ok soon. C.
[aur-general] Inactivity (again) - 12th-26th August
Hi all! This afternoon I'll be leaving for HAR (Hacking at Random) in Vierhouten, in the Netherlands! I'll be connected about 24/7 until Monday, but since there will be a lot of nice hackers around I won't probably be checking my Gmail (unless I find some time to setup IMAPS, I don't trust the web interface cookies =P) and won't generally connect to unencrypted services. There's a chance that I'll have a VPN set up from a friend of mine, but it's better to consider me inactive. I'll also have another week off after this, with little to no connection, and I'll be back on August, 26th, hopefully ready to do a better work on Arch than I did in these last few months =) Corrado
Re: [aur-general] [arch-dev-public] Integrity check emails
2009/9/19 Aaron Griffin : > Considering the notification list is private, do we want to send > integrity check emails somewhere else? > > I sent them here manually to illustrate the new-and-improved checking > Xavier added. That's a great thing - I now know I have a lot to fix :) > And yes, those duplicates are real dupes in community Dupes come mostly from the any-arch transition. In fact I had looked around a bit, but couldn't find some king of guide - what exactly should we untag on the repo to remove a specific architecture?
Re: [aur-general] [arch-dev-public] Integrity check emails
2009/9/19 Eric Bélanger : > On Fri, Sep 18, 2009 at 7:51 PM, Evangelos Foutras > wrote: >> I believe all you need to do is `svn rm' the unwanted repo from the repos >> directory and `svn commit'. That's what I did for a couple of my packages >> when I transitioned them to the 'any' arch. > > Yes, that's how you do it. There is a fix in git that will do that > automatically in the future. Thanks to both, I fixed my packages.
[aur-general] [TU signoff] pulseaudio-0.9.19
Hi fellow TUs, I've just moved the latest pulseaudio (x86_64 only, ATM) in [community-testing] because I'd like to get some feedback before committing. I had some problems because it failed to deliver any output with the default configuration (which is _bad_), and I had to manually activate the alsa-sink and alsa-source modules in /etc/pulse/default.pa. So in short, I'd like a couple of signoffs from TUs, but every feedback on this new version is welcome.
Re: [aur-general] Conventions on packages for cross-compiling
2009/10/7 Vojtech Horky : > Hi all, > I am seeking advice how to write correct PKGBUILDs for cross-compilers. > > The thing I am not sure about is where to install them. > Trouble is that even the binary packages use different locations and I > haven't found any other source where to get information from (for > example, cross-arm-wince-cegcc-binutils uses prefix /opt/cegcc/ while > mingw32-gcc uses /usr). > So, which location would you recommend/is better? Some time ago I asked the same question about my AVR toolchain, which is now in [community]. I think the original thread can be interesting to you: http://mailman.archlinux.org/pipermail/aur-general/2008-January/thread.html#611 > Another thing - is the correct naming convention 'cross--'? As you see, I just stuck with the '-arch' postfix =) Corrado
Re: [aur-general] [TU signoff] pulseaudio-0.9.19
2009/10/7 Aaron Griffin : > On Tue, Oct 6, 2009 at 6:46 PM, bardo wrote: >> Hi fellow TUs, >> I've just moved the latest pulseaudio (x86_64 only, ATM) in >> [community-testing] because I'd like to get some feedback before >> committing. I had some problems because it failed to deliver any >> output with the default configuration (which is _bad_), and I had to >> manually activate the alsa-sink and alsa-source modules in >> /etc/pulse/default.pa. >> >> So in short, I'd like a couple of signoffs from TUs, but every >> feedback on this new version is welcome. > > I just want to say that I think it's awesome you took it upon yourself > to do this :) You're my hero Don't make me blush now, I'm almost inactive, and this is just a small part of what I should do... BTW, i686 version is up, same considerations apply.
Re: [aur-general] TU Application
2009/10/10 Angel Velásquez : > Hi all, > > I'd like to re-apply to my TU position. This is just great! I'm very happy you can contribute again :)
Re: [aur-general] Conventions on packages for cross-compiling
2009/10/13 Allan McRae : > I have been looking into cross-compilers a lot lately, and I think the best > place to put _all_ their files is /usr/lib/cross-*-*-* and then symlink > needed stuff or add wrapper scripts in /usr/bin/. This is more FHS > compliant than the /usr/i486-mingw32 that is used in mingw32 and /usr/avr in > the avr one. Does your proposed build process lead to any "interesting" > directories in /usr? > > I am currently rebuilding the mingw32 packages to check if I can get this > working properly and will add comments to the wiki page in the coming days. Nice to see some discussion on this issue, once a standard is agreed I'll update my avr toolchain. Anyway, IIRC the FHS doesn't state anything cross-arch specific, but your proposal is surely cleaner (and more self-explanatory). Corrado
Re: [aur-general] [TU signoff] pulseaudio-0.9.19
2009/10/8 bardo : >>> So in short, I'd like a couple of signoffs from TUs, but every >>> feedback on this new version is welcome. Anybody? Anything? Should I understand that nobody uses [community-testing]? I just want to know if you can hear some audio without decommenting "alsa-source" and "alsa-sink" in default.pa on a per-user configuration...
Re: [aur-general] [arch-dev-public] audio packages
2009/11/21 Allan McRae : > There have been plenty of bugs about enabling pulseaudio support in various > packages but they are routinely closed with a "deferred until it is in > [extra]" message. To get better audio support we would probably want to > bring in at least pulseaudio, oss and portaudio from [community]. I maintain pulse in [community] and couldn't agree more, this package should go to [extra], since it is a makedepend for a lot of packages which many users have to rebuild by themselves at the moment. > So is there a current dev willing to maintain these? If anybody wants to step up, get in touch with me, I can recap on the current package situation and give a lot of tips for a mostly hassle-free maintenance. Since as far as I know not all devs read this ml, it could be a good idea if someone forwarded this message to arch-dev-public. Thanks, Corrado
Re: [aur-general] Trusted User Application
2009/11/23 Xyne : > Ok, the voting period for Ranguvar's TU application has begun.TUs, > please log in to the AUR and vote. Damn... never click when you're sleepy... I voted without changing my locale, and my vote wasn't registered. Need more coffee... and a block of the page if the locale isn't en.
[aur-general] LDFLAGS question
Hi all. Recently I've been having fun with the latest pulseaudio quirk: it doesn't build because of the --as-needed flag in linking. I don't understand linking in depth, but as I understood it there's some dependency cycle that gets triggered by the aforementioned ld flag. However this doesn't happen when building in a chroot, where the package builds fine. It isn't the only package where it happens, and I have a handful of questions about the correct way to handle this. 1. If something like this happens, is it an upstream bug? 2. If it builds fine in a chroot there's obviously a software that triggers the bug, does it mean I am missing a dependency? 3. If a package builds inside a chroot but not outside, should it be changed in such a way that it builds everywhere regardless of the changes that are to be made? Or should it be left as it is, and related bugs closed with "build it in a chroot"? 4. What does the absence of the ld flag imply in practical terms? Is it just a "nice to have" or has it some real implications?
Re: [aur-general] LDFLAGS question
2009/11/26 Allan McRae : > It is probably an addition dep (optional) that is being detected on your > system and causing the failure. Personally, I would build in a chroot and > ignore the issue. There are plenty of packages that should only be built in > a chroot due to issues similar to this and _ALL_ packages should be built in > one anyway. Well, it seems to be known and documented upstream, and they don't consider it as a bug: http://www.mail-archive.com/pulseaudio-disc...@mail.0pointer.de/msg04883.html
Re: [aur-general] LDFLAGS question
2009/11/26 Allan McRae : > I looks like pulse-audio will link to itself and that causes issues with > --as-needed. Heimdal had (has?) the same issue so had something like this > in the PKGBUILD: > > [ -e /usr/lib/libasn1.so ] && echo "## remove old heimdal pkg first ##" && > return 1 > > If pulse-audio only fails to build when pulse-audio is present, a line like > that in the PKGBUILD will solve all problems. Or just a comment at the top > like the current heimdal package: > > # > ### Attention: remove old pkg before building - it links against itself! ### > # Well, I like these solutions. The problem, though, kind of "solved" itself. I'm trying to build the brand new 0.9.21, and it also fails in a chroot with the same error. It doesn't make a lot of sense to me (the chroot is clean) but the errors are the same, so there must be some other package that causes this. Corrado
[aur-general] Help in building i686 packages needed
Since I'm experiencing problems with the aufs module (anyone else?) I'm currently unable to build i686 packages in a clean chroot. Can anybody help? At the moment I need gammu and wammu to be rebuilt. Thanks, Corrado
Re: [aur-general] Help in building i686 packages needed
2010/1/7 Ionut Biru : > can you elaborate more on what kind of problems do you have with aufs? Behavior is pretty random. Sometimes I'll just get the "wrong mount option" error when running makechrootpkg, sometimes module loading will hang, sometimes it'll print a stack trace and die, and even though the module appears to be loaded it doesn't work and cannot be removed. I think I remember somebody talking about similar problems on an arch list but I can't find it right now. This happens on my main machine (x86_64 on [testing]) and on my virtual building machine (i686 on 2.6.31, I don't care to update it since I use chroots in there too). It works on another x86_64 build machine, though, which still has 2.6.30. > i'll do those rebuilds now. Thanks a lot.
[aur-general] db-scripts glitch
Just had a little problem that required manual intervention on sigurd. I was running db-community, but it happened to be already running, so it stopped. It left a symlink behind, though, and it failed until I removed it. Here's the log, tomorrow I'll investigate the problem, now it's 4 am and I only have the energy to cut&paste. G'night. -- [cprim...@sigurd ~]$ /arch/db-community ==> Processing 1 new/updated arch-independent packages for 'community'... Checked out revision 7496. Validating package arch (any) eclipse-ve Checking SVN for eclipse-ve Updating DB for community-i686 ==> Copying DB file from 'community'... ==> Processing 1 new/updated packages for repository 'community'... D checkout/eclipse-ve Checked out revision 7496. ==> Extracting database to a temporary location... ==> Adding package 'eclipse-ve-1.4.0-1-any.pkg.tar.gz' ==> Creating updated database file 'community.db.tar.gz' Copying new files to '/srv/ftp/community/os/any' and symlinking error: db generation is already in progress (started by dgriffiths) [cprim...@sigurd ~]$ /arch/db-community ==> Processing 1 new/updated arch-independent packages for 'community'... Checked out revision 7496. Validating package arch (any) eclipse-ve Checking SVN for eclipse-ve Updating DB for community-i686 ==> Copying DB file from 'community'... ==> Processing 1 new/updated packages for repository 'community'... D checkout/eclipse-ve Checked out revision 7496. ==> Extracting database to a temporary location... ==> Adding package 'eclipse-ve-1.4.0-1-any.pkg.tar.gz' ==> WARNING: An entry for 'eclipse-ve-1.4.0-1' already existed ==> Creating updated database file 'community.db.tar.gz' Copying new files to '/srv/ftp/community/os/any' and symlinking ln: creating symbolic link `/srv/ftp/community/os/i686/eclipse-ve-1.4.0-1-any.pkg.tar.gz': File exists error: failed to make link for eclipse-ve-1.4.0-1-any.pkg.tar.gz. [cprim...@sigurd ~]$ ls -l /srv/ftp/community/os/i686/eclipse-ve-1.4.0-1-any.pkg.tar.gz lrwxrwxrwx 1 cprimier tusers 40 Jan 6 22:16 /srv/ftp/community/os/i686/eclipse-ve-1.4.0-1-any.pkg.tar.gz -> ../any/eclipse-ve-1.4.0-1-any.pkg.tar.gz [cprim...@sigurd ~]$ rm /srv/ftp/community/os/i686/eclipse-ve-1.4.0-1-any.pkg.tar.gz [cprim...@sigurd ~]$ /arch/db-community ==> Processing 1 new/updated arch-independent packages for 'community'... Checked out revision 7496. Validating package arch (any) eclipse-ve Checking SVN for eclipse-ve Updating DB for community-i686 ==> Copying DB file from 'community'... ==> Processing 1 new/updated packages for repository 'community'... D checkout/eclipse-ve Checked out revision 7496. ==> Extracting database to a temporary location... ==> Adding package 'eclipse-ve-1.4.0-1-any.pkg.tar.gz' ==> WARNING: An entry for 'eclipse-ve-1.4.0-1' already existed ==> Creating updated database file 'community.db.tar.gz' Copying new files to '/srv/ftp/community/os/any' and symlinking Updating DB for community-x86_64 ==> Copying DB file from 'community'... ==> Processing 1 new/updated packages for repository 'community'... Checked out revision 7496. ==> Extracting database to a temporary location... ==> Adding package 'eclipse-ve-1.4.0-1-any.pkg.tar.gz' ==> Creating updated database file 'community.db.tar.gz' Copying new files to '/srv/ftp/community/os/any' and symlinking [cprim...@sigurd ~]$
Re: [aur-general] Help in building i686 packages needed
2010/1/7 bardo : > I'm currently unable to build i686 packages in a clean chroot. Can > anybody help? I also need a rebuild on acerhk. It is an i686-only kernel module, a simple pkgrel bump should be more than enough. By the way, I don't even use the driver anymore, rebuilding is not much of a hassle, but if any TU uses it, feel free to take it. Thanks in advance, Corrado
[aur-general] Inactivity notice
Hi fellow TUs, I'm in the process of changing ISP. Theoretically the Italian law says you should have almost no downtime during the switch, in practice my old ISP was disconnected yesterday morning and the new one still hasn't taken over the line. I'm at the window writing this e-mail with a connection I... borrowed... from a kind neighbour. So, until further notice consider me as totally inactive, hopefully not for a long time, and feel free to take whatever action you feel appropriate with my package. If you do anything more complex than a bump+release it'd be nice to send me an e-mail, which I'll read later. Thanks to all, Corrado
Re: [aur-general] Inactivity notice
2010/1/12 bardo : > So, until further notice consider me as totally inactive, hopefully > not for a long time And a long time indeed has passed, but today I finally got my Internet connection back! I have a mile-long backlog to catch up with, but I'll try to sync with the rest of the world as soon as possible.
Re: [aur-general] Inactivity notice
2010/1/23 Xyne : > Welcome back to the internet! Thanks! I was starting to feel the abstinence =)
[aur-general] Removal of the last-exit player from [community]
Hi fellow TUs, the last-exit package needs to be rebuilt, but now that the streaming isn't free anymore it doesn't work with most accounts. Furthermore it is dead upstream and their domain was just squatted. If nobody wants to maintain it I'd drop it to the AUR. If nobody answers I'll move it in three days. Corrado
Re: [aur-general] Orphans in [community]-any
2010/2/2 Daniel Griffiths : > Here's the first batch of orphans in [community]. These are all in > arch=('any'). They are listed by last maintainer where possible, last > updater if no maintainer is listed. If no one wants to adopt them they will > be dropped to AUR. I have taken mine, thanks.
[aur-general] [FYI] Two new packages in community: libcuefile and libreplaygain
I finally managed to build the last musepack-tools release, but it now needs two small libraries (and relative headers) also published by the Musepack Team. I'm going to upload them as dependencies. Corrado
[aur-general] [FYI] New package in community: rtkit
Hi all. I just added (the x86_64 version of) rtkit to [community], it's a new dependency for the pulseaudio rebuild I'm going to upload shortly.
[aur-general] TU resignation
It's with great sadness that I feel the need to leave my position as a Trusted User in Arch. In the last few months I haven't been able to keep up with my duties, and I feel that resigning is the best thing I can do at the moment, since real life is taking much more time than there is in a day and I can't keep up with the high standards that Arch deserves. I'd like to thank each and everyone at the Arch team, this has been a fun ride and I learned a lot in these years. Hopefully I'll be back contributing someday, maybe not in the same way, but whatever. Surely I'll stick around, however, as much as my free time allows me. At the moment I own a few dozens of packages in [community], and since I'd like to make the transition as smooth as possible, a little report follows, I marked as OOD the ones which need to be updated, adopt the ones you like. I hope this is helpful. Take care, Corrado = AVR packages = The AVR family is badly in need of some love. The wonderful djgera did all the grunt work (see http://mailman.archlinux.org/pipermail/aur-general/2010-March/008369.html), now someone just has to take these little guys and update them. As with every toolchain, though, there's quite a bit to catch up with, and a whole lot to learn. Not for the faint of heart. * avrdude (OOD) * avr-libc (OOD) * binutils-avr (OOD) * gcc-avr (OOD) = PulseAudio & friends = These are really popular and still hope to go in [extra], because a lot of [extra] software could depend on them. The pulseaudio PKGBUILD needs some time to become friends with, not mentioning the package configuration, but if you stick to "stable" releases and refuse to patch the hell out of it as its author does in RedHat, you'll be fine. One open bug: http://bugs.archlinux.org/task/18527 * pulseaudio * gstreamer0.10-pulse * libao-pulse * libasyncns * padevchooser * paman * paprefs * pavucontrol * pavumeter * rtkit * xmms-pulse = Eclipse Plug-Ins = Mostly low-maintenance packages, they usually just need a relbump thanks to my super-unreadably-duper-perfectly-working PKGBUILDs. * eclipse-emf: needs to be ported to -any * eclipse-gef (OOD) * eclipse-mylyn (OOD) * eclipse-phpeclipse * eclipse-subclipse (OOD) * eclipse-ve = {G,W}ammu = A couple of programs to manage cell phones. Not always the easiest of builds but it's been stable for quite some time now. * gammu * wammu = Gmusicbrowser = My favorite music player, a tricky PKGBUILD (read: do everything by hand) but the developer is very friendly and helpful, and incredibly fast to reply. Optdepends hell. * gmusicbrowser * flac123 * perl-gstreamer * perl-gstreamer-interfaces (OOD) * perl-gtk2-mozembed = Musepack = Upstream releases are rare and not exactly packager-friendly. * musepack-tools * libcuefile * libreplaygain = Beast = Hasn't seen a release in ages, but it returned active upstream a few months ago. Usually needs patches. * beast * bse-alsa = Other = * acerhk: small kernel module, i686-only, no new releases, hassle free, just relbump * freemind: unvaluable mind-mapper, still waiting for the much anticipated 0.9.0, which will most likely arrive with Godot. Easy. * gnormalize: how to kill the unix do-one-thing-n-do-it-well paradigm in one shot. Optdepends hell #2 * gourmet (OOD): a recipe manager. Not that I can cook. * mldonkey: a p2p app for the edonkey network, gave me a few head scratches for the rc script. * opcion: a nice font viewer written in java, unmaintained but working very well. * rss-glx: 3d screen-savers, usually gives a few problems with .desktop files. See http://bugs.archlinux.org/task/18300 * scite (OOD): small text editor with some nice features, could be more friendly. * solfege (OOD): piece of cake! Frequent point releases, the development branch is stable, but I don't remember why I switched to it back in the day. * stress (OOD): small unix utility, clean and easy. * timidity-freepats: hasn't seen a release in ages and probably will be around forever. Zero maintenance, nice to have in repos. Could be ported to -any. * vlock: small unix utility, clean and easy. * wavegain: small util, optdepend for gnormalize * xsensors (OOD): X11 sensor viewing util
Re: [aur-general] Status of community cleanup 2010.
2010/8/30 Thomas Dziedzic : > mt-daapd x86_64 Community orphan This one works, and as far as I have seen it won't get any more releases, but it also will work indefinitely. The stable branch is long time dead, and svn seems too, but the svn head is very stable (been using it for a few months). The project has been renamed to Firefly (http://www.fireflymediaserver.org/), but the download page still points to the mt-daapd sourceforge tarballs. Conclusions: if anyone wants to adopt it, it seems to be in a good state and needs zero maintenance. After using it for a good while on my server, I'd also switch to the svn head (check mt-daapd-svn in the AUR for any differences). Otherwise, drop it! =) Corrado