Re: [aur-general] Problem uploading packages on i686

[bardo]

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

[bardo]

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

[bardo]

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

[bardo]

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

[bardo]

YES

Re: [aur-general] [arch-dev-public] abs tree checker

[bardo]

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

[bardo]

(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

[bardo]

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

[bardo]

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

[bardo]

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

[bardo]

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

[bardo]

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

[bardo]

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

[bardo]

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

[bardo]

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

[bardo]

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

[bardo]

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

[bardo]

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

[bardo]

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

[bardo]

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

[bardo]

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

[bardo]

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

[bardo]

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

[bardo]

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

[bardo]

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

[bardo]

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?

[bardo]

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

[bardo]

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

[bardo]

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

[bardo]

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

[bardo]

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

[bardo]

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

[bardo]

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

[bardo]

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]

[bardo]

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)

[bardo]

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]

[bardo]

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]

[bardo]

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

[bardo]

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

[bardo]

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.

[bardo]

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

[bardo]

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

[bardo]

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)

[bardo]

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

[bardo]

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

[bardo]

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

[bardo]

> 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

[bardo]

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

[bardo]

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

[bardo]

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

[bardo]

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

[bardo]

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

[bardo]

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

[bardo]

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

[bardo]

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

[bardo]

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

[bardo]

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

[bardo]

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

[bardo]

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

[bardo]

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

[bardo]

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

[bardo]

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

[bardo]

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

[bardo]

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

[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

Re: [aur-general] AVR toolchain update

[bardo]

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

[bardo]

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

[bardo]

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

[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 :)

Corrado

Re: [aur-general] Inactivity

[bardo]

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

[bardo]

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

[bardo]

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

[bardo]

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

[bardo]

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

[bardo]

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

[bardo]

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

[bardo]

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

[bardo]

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

[bardo]

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

[bardo]

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

[bardo]

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

[bardo]

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

[bardo]

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

[bardo]

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

[bardo]

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

[bardo]

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

[bardo]

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

[bardo]

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

[bardo]

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

[bardo]

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

[bardo]

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

[bardo]

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]

[bardo]

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

[bardo]

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

[bardo]

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

[bardo]

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

[bardo]

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.

[bardo]

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