[aur-general] Keeping community64 up to date
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
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 <allan.mcrae@qimr.edu.au> To: Discussion about the Arch User Repository (AUR) <aur-general@archlinux.org> 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
On Fri, Mar 21, 2008 at 7:07 PM, olivier bordes <olivier@obordes.com> 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
Abhishek Dasgupta wrote:
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.
What about just sending an email to this mailing list if you want someone to build a package you have uploaded for another architecture? It would create more traffic on the list but with an appropriate tag can easily be filtered.
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)
See http://wiki.archlinux.org/index.php/Community64_Status
Flag them + lib32* them and for the rest,
I against using lib32 packages as dependencies to get 32 bit binary packages to work withing the community64 repo. I think that if people want to get i686 binary blobs to work in x86_64 it should be done manually. Do we have an official policy on this?
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 <allan.mcrae@qimr.edu.au> To: Discussion about the Arch User Repository (AUR) <aur-general@archlinux.org> 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
Liviu Librescu - În veci pomenirea lui. (May his memory be eternal.)
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) -------- Original Message -------- Subject: Re:[aur-general] Keeping community64 up to date From: <w9ya@qrparci.net> To: aur-general@archlinux.org Date: ven 21 mar 2008 15:01:15 CET
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 <allan.mcrae@qimr.edu.au> To: Discussion about the Arch User Repository (AUR) <aur-general@archlinux.org> 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
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)
I agree. It would definitely be nice to be informed if there is a new comment about a package.
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
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
Olivier Bordes wrote:
Firmicus wrote:
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 the notify button, then package owner is *not* notified. At least, it did not worked for me. Olivier
I don't think the notify button is supposed to work the way you think it is. As I understand it, the person that wants to be notified about new comments has to enable notify, not the one posting the comment.
On Fri, 21 Mar 2008 21:37:20 +1000 Allan McRae <allan.mcrae@qimr.edu.au> 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. And, of course, there are some packages that have a shit of PKGBUILD (sorry for the word, but it's true in this case) and are impossible to compile on chroot. Sometimes I fix it, other times I want that maintainer do it himself. sergej: Most of these packages are yours. Remember the discussion that we had some months ago? You wrote that you're capable to maintain a large number of packages: and I know your skill, and I'm sure that you can do this: but please, try to sync 32 and 64 community. 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 ). 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? 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 -- JJDaNiMoTh - ArchLinux Trusted User
On Thu, Mar 27, 2008 at 4:54 PM, JJDaNiMoTh <jjdanimoth@gmail.com> 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. All other packages I maintain I build on the x86_64 build machine. At the moment two of these packages are behind the i686 ones (kaa-metadata & freevo) as they depend on kaa-base and I had to wait for the build machine to synchronize. I will build those today/tomorrow.
On Thu, 27 Mar 2008, Ronald van Haren wrote:
On Thu, Mar 27, 2008 at 4:54 PM, JJDaNiMoTh <jjdanimoth@gmail.com> 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.
Ronald van Haren wrote:
All other packages I maintain I build on the x86_64 build machine. At the moment two of these packages are behind the i686 ones (kaa-metadata & freevo) as they depend on kaa-base and I had to wait for the build machine to synchronize. I will build those today/tomorrow.
I sure they were in the list of packages I built last night, so you can skip those...
On Thu, 27 Mar 2008, JJDaNiMoTh wrote:
On Fri, 21 Mar 2008 21:37:20 +1000 Allan McRae <allan.mcrae@qimr.edu.au> 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.
JJDaNiMoTh wrote:
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.
I think the best we can hope for here is ~130 differences, with lib32 packages and i686 binary blobs. The difference list was at >300 three days ago....
sergej: Most of these packages are yours. Remember the discussion that we had some months ago? You wrote that you're capable to maintain a large number of packages: and I know your skill, and I'm sure that you can do this: but please, try to sync 32 and 64 community.
I second that... I build ~150 packages in the last two days and at least 120 of the were Sergej's. This is a bit extreme due to all his perl packages but I think the point remains.
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.
I can remember him posting about inactivity just after becoming a dev and have only seem evidence of his presence intermittently after that. I updated his geany package the other day. 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
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.
participants (13)
-
Abhishek Dasgupta
-
Allan McRae
-
Allan McRae
-
Collin
-
Eric Belanger
-
Firmicus
-
Jason Tarbet
-
JJDaNiMoTh
-
Olivier Bordes
-
olivier bordes
-
Ronald van Haren
-
Thomas Haider
-
w9ya＠qrparci.net