On Fri, Mar 21, 2008 at 7:07 PM, olivier bordes wrote:

Hi everybody,

I am new to this list, so excuse me if I ask stupid questions. I own a 64 bits machine, and feel that could help more on this 64 bits subject.

Several times, I had to install 64 bits packages which were not 64bits ready. I had to change the PKGBUILD to make it work (and sometimes more). It was fine for me, however the package was not updated for others. I have not found any way to make it available for others, except than to add a note to the package in AUR.

But it is not very efficient. Package maintainer may not read it or may not be available, etc...

As currently I am not TU, I wonder if there is any other way to further help on this. Your proposal Allan seems good to fit this needs, provided that non TU are allowed to update it. But still, you would have to update manually the PKGBUILD for the archictecture supported. How to do this when you are not the maintainer ?

my64

I think a better way would be as Allan suggested. There is no mechanism in place for a non-TU to upload packages to [community], let alone change the PKGBUILD. I think this synchronization would be made better if there is something to nag us always :) Maybe another ML (aur-community-sync) which would contain autonotifications about packages out of sync (with a certain threshold period of say 2-3 days) and we could easily see which ones were out of date. Any TU who would want to sync a particular package would reply to the [out-of-date] autonotification email, and that way we would know that there's someone taking care of it. A wiki would also do for the time being, though that has the disadvantage of non-automation. Another way to do this thing is to go through the list, checking which packages are i686 only or not (there was a post on this in the ML recently) Flag them + lib32* them and for the rest, feed the AUR community folder into a program which will start building packages for x86_64 (it is almost always x86_64 which lags behind). A kind of a build daemon; a web interface to see which packages have been built, and we can sync from that, test if it's working and then mark it for uploading to [community]. This is a bit far-fetched though :) We can always start with the wiki. - A

Courtesy should be important. Contact the maintainer directly and let them know what is wrong. OR, use the bug reporting system. You will be thanked for your efforts, and you will feel better about being courteous. Plus you will have educated someone instead of potentially making them angry by ignoring them when trying to directly change things. No one wants to be ignored, so please consider taking the time to send a note to the "maintainer". Very best regards; Bob Finch

Hi everybody,

I am new to this list, so excuse me if I ask stupid questions. I own a 64 bits machine, and feel that could help more on this 64 bits subject.

Several times, I had to install 64 bits packages which were not 64bits ready. I had to change the PKGBUILD to make it work (and sometimes more). It was fine for me, however the package was not updated for others. I have not found any way to make it available for others, except than to add a note to the package in AUR.

But it is not very efficient. Package maintainer may not read it or may not be available, etc...

As currently I am not TU, I wonder if there is any other way to further help on this. Your proposal Allan seems good to fit this needs, provided that non TU are allowed to update it. But still, you would have to update manually the PKGBUILD for the archictecture supported. How to do this when you are not the maintainer ?

my64

-------- Original Message -------- Subject: [aur-general] Keeping community64 up to date From: Allan McRae To: Discussion about the Arch User Repository (AUR) Date: ven 21 mar 2008 12:37:20 CET

...

Hi,

I have come to realize that the current way of keeping community64 in sync could use some improving. I realized this when looking at the pkg_diff web page [1] thinking I would build some packages. After being distracted by the internet for a few minutes... I reloaded the page and noticed that some of the packages had been uploaded. Now had I actually built those packages, it would have been a waste of time. Also, I'm never sure how much time to wait and see whether the TU who uploaded the i686 package is going to upload the x86_64 package.

How can this be improved? The best I can come up with is making a wiki page with a list of x86_64 build requests. TU's who upload a i686 package and are not going to build the x86_64 package themselves would need to add the package to the page. Think of it as punishment for not building it yourself. :) When someone else goes to build the package they either remove it from the list or tag that it is being built.

That probably isn't the best idea, but I feel that the current system is a bit flawed. Any other suggestions/comments?

Allan

[1] http://dev.archlinux.org/~andyrtr/pkg_diff.html

Liviu Librescu - În veci pomenirea lui. (May his memory be eternal.)

In my opinion it should always email the package maintainer when someone leaves a comment about a package of theirs. It makes no sense not to. olivier bordes wrote:

I agree that the maintainer should always be informed about bugs, enhancements and no change should be done without his agreement.

Note that in my case, I try as often as possible to leave a comment under AUR to the attention of the package maintainer. But this looks to be NOT sufficient as the maintainer may not read it, and you confirmed that it does not replace a mail directly sent to the maintainer.

Tell me why I thought that package maintainer was automagically informed by these comments in AUR ??? ;)

Olivier (my64)

Jason Tarbet wrote:

I agree. It would definitely be nice to be informed if there is a new comment about a package.

There is the notify button in AUR...

Allan McRae a écrit :

...

Jason Tarbet wrote:

...

I agree. It would definitely be nice to be informed if there is a new comment about a package.

There is the notify button in AUR...

Yes, and unless I am fabulating, it USED to work automatically, that is, whenever one adopted a package, you would be automatically notified. Now one has to do it manually. But correct me if I am wrong!

F Well, it seems not working. If you just add a comment, without hitting

Firmicus wrote: the notify button, then package owner is *not* notified. At least, it did not worked for me. Olivier

On Thu, 27 Mar 2008, Ronald van Haren wrote:

On Thu, Mar 27, 2008 at 4:54 PM, JJDaNiMoTh wrote:

...

pressh: Your e17 packages are effectively hard to maintain ( for circular dep, and others that you explain here ). Do you have a 64 hardware or you need an hand? In this case, tell us ( a solution could be found ).

I don't have much time at the moment to answer all your questions, so at this point I only answer the question directed to me. I may find time later tonight (or someone else may have jumped in by then) to discuss more about syncing i686 and x86_64.

No I have no x86_64 hardware :( so I only build i686 myself. Eric (Snowman) is building the x86_64 e17 packages. He usually updates the x86_64 within a few days after I update the i686 packages (which I do on a two weekly basis), that is if he has the time to do so. I noticed he missed the last update (10 days ago), but I assume this is because he is busy doing more important things. I expect him to update the x86_64 packages on the next update. I keep an eye on it so if major lagging occurs I will contact him, or scream for help here so someone else can jump in.

Yes, I'll update e17 on next update unless someone else wants to start building the x86_64 packages for it. I was busy with real life. Also I had packages to update/build for the official repo. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.

On Thu, 27 Mar 2008, JJDaNiMoTh wrote:

On Fri, 21 Mar 2008 21:37:20 +1000 Allan McRae wrote:

...

Hi,

I have come to realize that the current way of keeping community64 in sync could use some improving. I realized this when looking at the pkg_diff web page [1] thinking I would build some packages. After being distracted by the internet for a few minutes... I reloaded the page and noticed that some of the packages had been uploaded. Now had I actually built those packages, it would have been a waste of time. Also, I'm never sure how much time to wait and see whether the TU who uploaded the i686 package is going to upload the x86_64 package.

Uhm... maybe the man that has uploaded these packages was I :)

Simply, at this point, with Aaron's building machine and some of us which have 32/64 bit hardware, I don't understand why there are ~ 150 different packages from 32 to 64 bit community.

You also need to consider that the 32 and 64 community repo will never be completely in sync because of lib32 stuff and of packages that don't work on x86_64.

Last thing: we some packages maintained by devs in community or community64 out-of-date, and recompile it seems do not work because the older release. What we need to do?

Inform the maintainer. Offer to do the update for both arch if they are too busy to do it.

Last last: What about dtw? We have a lot of his packages in community out-of-dated [1], in this page [2] seems he isn't a TU, but has 3 bug opened [3]. IMHO, the best is moving all his packages back to unsupported and close bug assigned to him.

[1] http://aur.archlinux.org/packages.php?K=dtw&SeB=m [2] http://wiki.archlinux.org/index.php/Trusted_Users [3] http://bugs.archlinux.org/index.php?string=&project=5&search_name=&type[]=&sev[]=&pri[]=&due[]=&reported[]=&cat[]=&status[]=open&percent[]=&opened=&dev=dtw&closed=&duedatefrom=&duedateto=&changedfrom=&changedto=&openedfrom=&openedto=&closedfrom=&closedto=&do=index

I think dtw is unofficially inactive. Email him to ask about his status. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.

On Fri, 28 Mar 2008, Allan McRae wrote:

Can I just add, do we have a x86_64 TU who uses KDE. There are several KDE packages waiting to be built but I am running out of bandwidth for the month and don't want to download all the dependancies. Same goes for jdk. Allan

I could do some tonight as I needs to work on community (e17 update). -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.