[arch-dev-public] The move to SVN

Aaron Griffin

1 Apr 2008 1 Apr '08

1:22 a.m.

For the rest of the week, I am going to be concentrating on one big thing: moving our repos to SVN. Why is this important, after all the stuff I've been griping about, you may ask? Because it's a 'blocker'. It's the most low-level building block for a lot of the other changes I'd like to see done regarding our repository management So, here's the plan. I need one day where we make the switch over. It will be rocky and annoying for that day, but it is also a break for all of you Here are the steps that this will involve: Set all the cvs repos to RO, so that we don't have any accidents Convert everything to svn Make the necessary structure changes Make devtools changes * Make abs changes * Make db-scripts changes * Make changes to community ** * Can be done before hand, without a new package release ** Paul and Simo, in need your input regarding doing this for community as well. I have not looked at the scripts in a long time, but how much effort do you think this would take? Here is the end result, repo created ages ago by Jason[1]: http://projects.xennet.org/svnarch/ It is a tad large, but SVN is nice in that it allows us to only check out subdirs we want, so you can checkout just your packages (see jason's archco tool[1]) We *will* lose history during this transition. It's something I'm willing to live with, as this is not code history. We will still archive CVS for posterity. So, what do I need from you? Nothing. I'm making this easy in that I will do all the work. I just need one thing: give me a day when it is best. When you all want to take a mini-vacation and do no packaging at all. If no one has a good day for this, I will probably do it on Thursday or Friday. Thanks, Aaron 1: http://archlinux.org/pipermail/arch-dev-public/2007-October/002308.html

Show replies by date

Travis Willard

1 Apr 1 Apr

1:29 a.m.

Thursday works best for me, but I'm not objectionable to it happening any other day (since I'm busy Friday night) As I mentioned on Jabber, I've got an rsync-based ABS script totally ready for a testrun or two. In fact, I think I'll commit it to the ABS repo tonight so's you can have a look-see if you want. I'm still unsure how to generate the rsync repo to pull from. Would a db-scripts patch work best, do you think? We can co-ordinate on this if you want, I'm perfectly willing to do the work for that. On Mon, Mar 31, 2008 at 5:22 PM, Aaron Griffin wrote:

...

For the rest of the week, I am going to be concentrating on one big thing: moving our repos to SVN.

Why is this important, after all the stuff I've been griping about, you may ask? Because it's a 'blocker'. It's the most low-level building block for a lot of the other changes I'd like to see done regarding our repository management

So, here's the plan. I need one day where we make the switch over. It will be rocky and annoying for that day, but it is also a break for all of you

Here are the steps that this will involve: Set all the cvs repos to RO, so that we don't have any accidents Convert everything to svn Make the necessary structure changes Make devtools changes * Make abs changes * Make db-scripts changes * Make changes to community **

* Can be done before hand, without a new package release ** Paul and Simo, in need your input regarding doing this for community as well. I have not looked at the scripts in a long time, but how much effort do you think this would take?

Here is the end result, repo created ages ago by Jason[1]: http://projects.xennet.org/svnarch/

It is a tad large, but SVN is nice in that it allows us to only check out subdirs we want, so you can checkout just your packages (see jason's archco tool[1])

We *will* lose history during this transition. It's something I'm willing to live with, as this is not code history. We will still archive CVS for posterity.

So, what do I need from you? Nothing. I'm making this easy in that I will do all the work. I just need one thing: give me a day when it is best. When you all want to take a mini-vacation and do no packaging at all. If no one has a good day for this, I will probably do it on Thursday or Friday.

Thanks, Aaron

1: http://archlinux.org/pipermail/arch-dev-public/2007-October/002308.html

Aaron Griffin

1:39 a.m.

Top posting, wheee 8) On Mon, Mar 31, 2008 at 4:29 PM, Travis Willard wrote:

...

As I mentioned on Jabber, I've got an rsync-based ABS script totally ready for a testrun or two. In fact, I think I'll commit it to the ABS repo tonight so's you can have a look-see if you want.

I'm still unsure how to generate the rsync repo to pull from. Would a db-scripts patch work best, do you think? We can co-ordinate on this if you want, I'm perfectly willing to do the work for that.

I think you should assume, for the time being, that the rsync directory is there. We should have a checkout that is synced on each commit, I think. But it could even be a cron job - for right now, assume it just exists, unless you want to figure out the best/simplest way to do that. I'd probably start off with a cron job, just for the "path of least resistance" part of it

Jason Chu

1:50 a.m.

On Mon, Mar 31, 2008 at 04:39:18PM -0500, Aaron Griffin wrote:

...

Top posting, wheee 8)

On Mon, Mar 31, 2008 at 4:29 PM, Travis Willard wrote:

...
As I mentioned on Jabber, I've got an rsync-based ABS script totally ready for a testrun or two. In fact, I think I'll commit it to the ABS repo tonight so's you can have a look-see if you want.

I'm still unsure how to generate the rsync repo to pull from. Would a db-scripts patch work best, do you think? We can co-ordinate on this if you want, I'm perfectly willing to do the work for that.

I think you should assume, for the time being, that the rsync directory is there. We should have a checkout that is synced on each commit, I think. But it could even be a cron job - for right now, assume it just exists, unless you want to figure out the best/simplest way to do that. I'd probably start off with a cron job, just for the "path of least resistance" part of it

Agreed a cron job would be the easiest. It's a simple script that would have to find all the repos/<blah> directories and extract their contents. I may write one and just test it with my old svnarch repo. Jason

Aaron Griffin

2:26 a.m.

On Mon, Mar 31, 2008 at 4:50 PM, Jason Chu wrote:

...

On Mon, Mar 31, 2008 at 04:39:18PM -0500, Aaron Griffin wrote:

...
Top posting, wheee 8)

On Mon, Mar 31, 2008 at 4:29 PM, Travis Willard wrote:

...
As I mentioned on Jabber, I've got an rsync-based ABS script totally ready for a testrun or two. In fact, I think I'll commit it to the ABS repo tonight so's you can have a look-see if you want.

I'm still unsure how to generate the rsync repo to pull from. Would a db-scripts patch work best, do you think? We can co-ordinate on this if you want, I'm perfectly willing to do the work for that.

I think you should assume, for the time being, that the rsync directory is there. We should have a checkout that is synced on each commit, I think. But it could even be a cron job - for right now, assume it just exists, unless you want to figure out the best/simplest way to do that. I'd probably start off with a cron job, just for the "path of least resistance" part of it

Agreed a cron job would be the easiest. It's a simple script that would have to find all the repos/<blah> directories and extract their contents.

I may write one and just test it with my old svnarch repo.

Yeah, it's easy, but also may be lost effort if done poorly, as it won't be able to do the "up to date" check, it will have to do a full CO each time... as long as we keep some sort of perma-checkout sitting somewhere... /me shrugs

Jason Chu

3:31 a.m.

On Mon, Mar 31, 2008 at 05:26:33PM -0500, Aaron Griffin wrote:

...

On Mon, Mar 31, 2008 at 4:50 PM, Jason Chu wrote:

...
On Mon, Mar 31, 2008 at 04:39:18PM -0500, Aaron Griffin wrote:

...
Top posting, wheee 8)

On Mon, Mar 31, 2008 at 4:29 PM, Travis Willard wrote:

...
As I mentioned on Jabber, I've got an rsync-based ABS script totally ready for a testrun or two. In fact, I think I'll commit it to the ABS repo tonight so's you can have a look-see if you want.

I'm still unsure how to generate the rsync repo to pull from. Would a db-scripts patch work best, do you think? We can co-ordinate on this if you want, I'm perfectly willing to do the work for that.

I think you should assume, for the time being, that the rsync directory is there. We should have a checkout that is synced on each commit, I think. But it could even be a cron job - for right now, assume it just exists, unless you want to figure out the best/simplest way to do that. I'd probably start off with a cron job, just for the "path of least resistance" part of it

Agreed a cron job would be the easiest. It's a simple script that would have to find all the repos/<blah> directories and extract their contents.

I may write one and just test it with my old svnarch repo.

Yeah, it's easy, but also may be lost effort if done poorly, as it won't be able to do the "up to date" check, it will have to do a full CO each time... as long as we keep some sort of perma-checkout sitting somewhere... /me shrugs

Yeah, planned on keeping a perma-checkout sitting somewhere ;) Jason

Dan McGee

4:27 a.m.

On Mon, Mar 31, 2008 at 6:31 PM, Jason Chu wrote:

...

On Mon, Mar 31, 2008 at 05:26:33PM -0500, Aaron Griffin wrote:

...
On Mon, Mar 31, 2008 at 4:50 PM, Jason Chu wrote:

...
On Mon, Mar 31, 2008 at 04:39:18PM -0500, Aaron Griffin wrote:

...
Top posting, wheee 8)

On Mon, Mar 31, 2008 at 4:29 PM, Travis Willard wrote:

...
As I mentioned on Jabber, I've got an rsync-based ABS script totally ready for a testrun or two. In fact, I think I'll commit it to the ABS repo tonight so's you can have a look-see if you want.

I'm still unsure how to generate the rsync repo to pull from. Would a db-scripts patch work best, do you think? We can co-ordinate on this if you want, I'm perfectly willing to do the work for that.

I think you should assume, for the time being, that the rsync directory is there. We should have a checkout that is synced on each commit, I think. But it could even be a cron job - for right now, assume it just exists, unless you want to figure out the best/simplest way to do that. I'd probably start off with a cron job, just for the "path of least resistance" part of it

Agreed a cron job would be the easiest. It's a simple script that would have to find all the repos/<blah> directories and extract their contents.

I may write one and just test it with my old svnarch repo.

Yeah, it's easy, but also may be lost effort if done poorly, as it won't be able to do the "up to date" check, it will have to do a full CO each time... as long as we keep some sort of perma-checkout sitting somewhere... /me shrugs

Yeah, planned on keeping a perma-checkout sitting somewhere ;)

Da wurde beschlossen, auf der privaten Mailing-Liste, die Diskussion muss in erster Deutscher mit einer englischen Übersetzung folgt. Bitte befolgen diese Regel. (sorry if my German is not quite up to par, but I am learning as fast as I can on my own) -Dan

Travis Willard

4:35 a.m.

On Mon, Mar 31, 2008 at 8:27 PM, Dan McGee wrote:

...

On Mon, Mar 31, 2008 at 6:31 PM, Jason Chu wrote:

...
On Mon, Mar 31, 2008 at 05:26:33PM -0500, Aaron Griffin wrote:

...
On Mon, Mar 31, 2008 at 4:50 PM, Jason Chu wrote:

...
On Mon, Mar 31, 2008 at 04:39:18PM -0500, Aaron Griffin wrote:

...
Top posting, wheee 8)

On Mon, Mar 31, 2008 at 4:29 PM, Travis Willard wrote:

...
As I mentioned on Jabber, I've got an rsync-based ABS script totally ready for a testrun or two. In fact, I think I'll commit it to the ABS repo tonight so's you can have a look-see if you want.

I'm still unsure how to generate the rsync repo to pull from. Would a db-scripts patch work best, do you think? We can co-ordinate on this if you want, I'm perfectly willing to do the work for that.

I think you should assume, for the time being, that the rsync directory is there. We should have a checkout that is synced on each commit, I think. But it could even be a cron job - for right now, assume it just exists, unless you want to figure out the best/simplest way to do that. I'd probably start off with a cron job, just for the "path of least resistance" part of it

Agreed a cron job would be the easiest. It's a simple script that would have to find all the repos/<blah> directories and extract their contents.

I may write one and just test it with my old svnarch repo.

Yeah, it's easy, but also may be lost effort if done poorly, as it won't be able to do the "up to date" check, it will have to do a full CO each time... as long as we keep some sort of perma-checkout sitting somewhere... /me shrugs

Yeah, planned on keeping a perma-checkout sitting somewhere ;)

Da wurde beschlossen, auf der privaten Mailing-Liste, die Diskussion muss in erster Deutscher mit einer englischen Übersetzung folgt. Bitte befolgen diese Regel. (sorry if my German is not quite up to par, but I am learning as fast as I can on my own)

Hey, _I_ voted for English. I love English. I can skew it any which way I want. You people and your German. I STILL REFUSE. In fact, I QUIT. Unden Quitten.

Jason Chu

4:49 a.m.

On Mon, Mar 31, 2008 at 07:27:58PM -0500, Dan McGee wrote:

...

On Mon, Mar 31, 2008 at 6:31 PM, Jason Chu wrote:

...
On Mon, Mar 31, 2008 at 05:26:33PM -0500, Aaron Griffin wrote:

...
On Mon, Mar 31, 2008 at 4:50 PM, Jason Chu wrote:

...
On Mon, Mar 31, 2008 at 04:39:18PM -0500, Aaron Griffin wrote:

...
Top posting, wheee 8)

On Mon, Mar 31, 2008 at 4:29 PM, Travis Willard wrote:

...
As I mentioned on Jabber, I've got an rsync-based ABS script totally ready for a testrun or two. In fact, I think I'll commit it to the ABS repo tonight so's you can have a look-see if you want.

I'm still unsure how to generate the rsync repo to pull from. Would a db-scripts patch work best, do you think? We can co-ordinate on this if you want, I'm perfectly willing to do the work for that.

I think you should assume, for the time being, that the rsync directory is there. We should have a checkout that is synced on each commit, I think. But it could even be a cron job - for right now, assume it just exists, unless you want to figure out the best/simplest way to do that. I'd probably start off with a cron job, just for the "path of least resistance" part of it

Agreed a cron job would be the easiest. It's a simple script that would have to find all the repos/<blah> directories and extract their contents.

I may write one and just test it with my old svnarch repo.

Yeah, it's easy, but also may be lost effort if done poorly, as it won't be able to do the "up to date" check, it will have to do a full CO each time... as long as we keep some sort of perma-checkout sitting somewhere... /me shrugs

Yeah, planned on keeping a perma-checkout sitting somewhere ;)

Da wurde beschlossen, auf der privaten Mailing-Liste, die Diskussion muss in erster Deutscher mit einer englischen Übersetzung folgt. Bitte befolgen diese Regel. (sorry if my German is not quite up to par, but I am learning as fast as I can on my own)

Es tut mir wirklich leid, dass ich die Regeln gebrochen habe. In Zukunft werde ich mich bemühen alle meine weiteren Emails in dieser Liste auf Deutsch zu schreiben. Jason Oprius -- We import Germans

Travis Willard

2 Apr 2 Apr

7:50 p.m.

On Mon, Mar 31, 2008 at 7:31 PM, Jason Chu wrote:

...

On Mon, Mar 31, 2008 at 05:26:33PM -0500, Aaron Griffin wrote:

...
On Mon, Mar 31, 2008 at 4:50 PM, Jason Chu wrote:

...
On Mon, Mar 31, 2008 at 04:39:18PM -0500, Aaron Griffin wrote:

...
Top posting, wheee 8)

On Mon, Mar 31, 2008 at 4:29 PM, Travis Willard wrote:

...
As I mentioned on Jabber, I've got an rsync-based ABS script totally ready for a testrun or two. In fact, I think I'll commit it to the ABS repo tonight so's you can have a look-see if you want.

I'm still unsure how to generate the rsync repo to pull from. Would a db-scripts patch work best, do you think? We can co-ordinate on this if you want, I'm perfectly willing to do the work for that.

I think you should assume, for the time being, that the rsync directory is there. We should have a checkout that is synced on each commit, I think. But it could even be a cron job - for right now, assume it just exists, unless you want to figure out the best/simplest way to do that. I'd probably start off with a cron job, just for the "path of least resistance" part of it

Agreed a cron job would be the easiest. It's a simple script that would have to find all the repos/<blah> directories and extract their contents.

I may write one and just test it with my old svnarch repo.

Yeah, it's easy, but also may be lost effort if done poorly, as it won't be able to do the "up to date" check, it will have to do a full CO each time... as long as we keep some sort of perma-checkout sitting somewhere... /me shrugs

Yeah, planned on keeping a perma-checkout sitting somewhere ;)

So, uh, yeah. Now that it's April 2 and I clearly didn't quit, there's a new version of ABS in git that uses rsync to do its business. It's heavily based off Eliott's work, and tested decently thoroughly, so I think it's good to go. Thanks Eliott! Basically, it expects the ABS tree to be stored on the server in the format: ${RSYNC_ROOT}/{$ARCH}/${REPO}/* Where RSYNC_ROOT is wherever the rsync stanza points to (currently /srv/abs), ARCH is i686 or x86_64, and REPO is the repo. Anything in that tree will be synch'd for that repo. I've currently got some static checkouts sitting in /srv/abs for each repo that can probably just be updated (except for testing) on a fairly-frequent basis with "cvs update" thanks to sticky-tags, and can change to whatever svn method we need when we change to svn. I wasn't sure how to get multiple repos checked out into the same dir for testing, and didn't spend a lot of time looking at it since we're switching to svn anyway. Anyway, yeah. New ABS is in git. Whee. I'll probably try to close the one FS report I've got for makeworld and get some of the todo list for makeworld completed before I actually tag as 2.0, though. We'll see how much I get done.

eliott

8:30 p.m.

...

So, uh, yeah. Now that it's April 2 and I clearly didn't quit, there's a new version of ABS in git that uses rsync to do its business. It's heavily based off Eliott's work, and tested decently thoroughly, so I think it's good to go. Thanks Eliott!

Basically, it expects the ABS tree to be stored on the server in the format:

${RSYNC_ROOT}/{$ARCH}/${REPO}/*

Where RSYNC_ROOT is wherever the rsync stanza points to (currently /srv/abs), ARCH is i686 or x86_64, and REPO is the repo. Anything in that tree will be synch'd for that repo.

I've currently got some static checkouts sitting in /srv/abs for each repo that can probably just be updated (except for testing) on a fairly-frequent basis with "cvs update" thanks to sticky-tags, and can change to whatever svn method we need when we change to svn.

I wasn't sure how to get multiple repos checked out into the same dir for testing, and didn't spend a lot of time looking at it since we're switching to svn anyway.

Anyway, yeah. New ABS is in git. Whee. I'll probably try to close the one FS report I've got for makeworld and get some of the todo list for makeworld completed before I actually tag as 2.0, though. We'll see how much I get done.

This is good news. Thanks for all the work Travis.

Roman Kyrylych

1 Apr 1 Apr

1:45 a.m.

2008/4/1, Aaron Griffin :

...

For the rest of the week, I am going to be concentrating on one big thing: moving our repos to SVN.

Finally! Huge thanks for stepping into this! :-)

...

We *will* lose history during this transition. It's something I'm willing to live with, as this is not code history. We will still archive CVS for posterity.

:-/ I would prefer to keep history, but if there's no (easy enought) way to do this - I'm fine without history, especially when CVS archive is kept for some time (BTW, this is a good example where ChangeLog file with important changes comes handy, especially for important packages). What I'm concerned about is the status of community. Scripts seem to be pretty old (don't understand -arch suffix yet). If our AUR heros can move this to SVN in pretty short time (few days?) - that would be awesome. I can help with aurtools/devtools modification/testing and changing guidelines for TUs. -- Roman Kyrylych (Роман Кирилич)

Aaron Griffin

2:23 a.m.

On Mon, Mar 31, 2008 at 4:45 PM, Roman Kyrylych wrote:

...

2008/4/1, Aaron Griffin :

...
For the rest of the week, I am going to be concentrating on one big thing: moving our repos to SVN.

Finally! Huge thanks for stepping into this! :-)

...
We *will* lose history during this transition. It's something I'm willing to live with, as this is not code history. We will still archive CVS for posterity.

:-/ I would prefer to keep history, but if there's no (easy enought) way to do this - I'm fine without history, especially when CVS archive is kept for some time (BTW, this is a good example where ChangeLog file with important changes comes handy, especially for important packages).

We all wish we could keep history, but it's going to be nearly unusable and going to make the conversion process take obscenely longer. I have talked it over with Dan and Jason, as far as the best way to do this conversion, and we all agree that losing the history is a better cost than the added effort for keeping it. The CVS archive will be kept as long as we need it (years?).

...

What I'm concerned about is the status of community. Scripts seem to be pretty old (don't understand -arch suffix yet). If our AUR heros can move this to SVN in pretty short time (few days?) - that would be awesome. I can help with aurtools/devtools modification/testing and changing guidelines for TUs.

One step at a time please. The community scripts are my next point of attack, so lets just stick with the SVn conversion for right now. I am already talking over the technical details with Paul and Simo, and switching to svn is easy. Path of least resistance. The next thing I tackle like this will be the community management scripts, so don't fear.

Jason Chu

1:55 a.m.

On Mon, Mar 31, 2008 at 04:22:05PM -0500, Aaron Griffin wrote:

...

For the rest of the week, I am going to be concentrating on one big thing: moving our repos to SVN.

Yay!

...

Why is this important, after all the stuff I've been griping about, you may ask? Because it's a 'blocker'. It's the most low-level building block for a lot of the other changes I'd like to see done regarding our repository management

So, here's the plan. I need one day where we make the switch over. It will be rocky and annoying for that day, but it is also a break for all of you

Here are the steps that this will involve: Set all the cvs repos to RO, so that we don't have any accidents Convert everything to svn Make the necessary structure changes Make devtools changes *

I can make some of the devtools changes necessary, but it'll be a little difficult to test until we have the svn repo in place.

...

Make abs changes * Make db-scripts changes *

How many of these will there be? What were the other plans for db-scripts changes?

...

Make changes to community **

Do we have to do this? I realize that it will just be more of an excuse to not make changes, but there are a lot more things in here that we don't need to support the official repos.

...

* Can be done before hand, without a new package release ** Paul and Simo, in need your input regarding doing this for community as well. I have not looked at the scripts in a long time, but how much effort do you think this would take?

Here is the end result, repo created ages ago by Jason[1]: http://projects.xennet.org/svnarch/

It is a tad large, but SVN is nice in that it allows us to only check out subdirs we want, so you can checkout just your packages (see jason's archco tool[1])

We *will* lose history during this transition. It's something I'm willing to live with, as this is not code history. We will still archive CVS for posterity.

So, what do I need from you? Nothing. I'm making this easy in that I will do all the work. I just need one thing: give me a day when it is best. When you all want to take a mini-vacation and do no packaging at all. If no one has a good day for this, I will probably do it on Thursday or Friday.

Any day is good for me... what me update packages? Jason

Jeff Mickey

2:14 a.m.

Any day is fine with me, just give me a heads up 24 or 12 hours beforehand, so I'm sure to have gotten the email/jabber/love. As long as the changes are made to community as well, I think this will be great! Thank you for taking this on Aaron. Final note: I think the history of PKGBUILD's is pretty insignificant. If you can give me a great use-case for PKGBUILD history, I may be swayed in this opinion.. but to switch away from CVS is more important than the history. To me, CVS is the equivalent of being stabbed in the face. I'd really like it to stop stabbing me. // jeff -- . : [ + carpe diem totus tuus + ] : .

Jan de Groot

2:31 a.m.

On Mon, 2008-03-31 at 18:14 -0400, Jeff Mickey wrote:

...

Any day is fine with me, just give me a heads up 24 or 12 hours beforehand, so I'm sure to have gotten the email/jabber/love. As long as the changes are made to community as well, I think this will be great! Thank you for taking this on Aaron.

Final note: I think the history of PKGBUILD's is pretty insignificant. If you can give me a great use-case for PKGBUILD history, I may be swayed in this opinion.. but to switch away from CVS is more important than the history. To me, CVS is the equivalent of being stabbed in the face. I'd really like it to stop stabbing me.

// jeff

When keeping CVS read-only online, I see no reason to keep history. The only reason to keep history for me is, well, to look at older revisions of a package (when did we break this, who broke it and why is this line here). When keeping a read-only CVS archive online, we can also check those things out.

Aaron Griffin

2:34 a.m.

On Mon, Mar 31, 2008 at 5:31 PM, Jan de Groot wrote:

...

On Mon, 2008-03-31 at 18:14 -0400, Jeff Mickey wrote:

...
Any day is fine with me, just give me a heads up 24 or 12 hours beforehand, so I'm sure to have gotten the email/jabber/love. As long as the changes are made to community as well, I think this will be great! Thank you for taking this on Aaron.

Final note: I think the history of PKGBUILD's is pretty insignificant. If you can give me a great use-case for PKGBUILD history, I may be swayed in this opinion.. but to switch away from CVS is more important than the history. To me, CVS is the equivalent of being stabbed in the face. I'd really like it to stop stabbing me.

// jeff

When keeping CVS read-only online, I see no reason to keep history. The only reason to keep history for me is, well, to look at older revisions of a package (when did we break this, who broke it and why is this line here). When keeping a read-only CVS archive online, we can also check those things out.

Agreed. We will also need to switch the web interface and I *think* that ViewVC works for both cvs and svn repos. Haven't looked to hard at it.

Roman Kyrylych

10:37 a.m.

2008/4/1, Aaron Griffin :

...

Agreed. We will also need to switch the web interface and I *think* that ViewVC works for both cvs and svn repos. Haven't looked to hard at it.

I think ViewVC is just a renamed ViewCVS afrer SVN support was added (and a lot of other changes too). -- Roman Kyrylych (Роман Кирилич)

Aaron Griffin

8:06 p.m.

On Tue, Apr 1, 2008 at 1:37 AM, Roman Kyrylych wrote:

...

2008/4/1, Aaron Griffin :

...
Agreed. We will also need to switch the web interface and I *think* that ViewVC works for both cvs and svn repos. Haven't looked to hard at it.

I think ViewVC is just a renamed ViewCVS afrer SVN support was added (and a lot of other changes too).

Yeah. If anyone knows some good web-viewer alternatives here, let me know. Simo mentioned that ViewVC is a pain in the ass, so maybe we want like... WebSVN or something? /me shrugs

Pierre Schmitz

8:12 p.m.

Am Dienstag, 1. April 2008 18:06:09 schrieb Aaron Griffin:

...

On Tue, Apr 1, 2008 at 1:37 AM, Roman Kyrylych wrote:

...
2008/4/1, Aaron Griffin :

...
Agreed. We will also need to switch the web interface and I *think*

that ViewVC works for both cvs and svn repos. Haven't looked to hard at it.

I think ViewVC is just a renamed ViewCVS afrer SVN support was added (and a lot of other changes too).

Yeah. If anyone knows some good web-viewer alternatives here, let me know. Simo mentioned that ViewVC is a pain in the ass, so maybe we want like... WebSVN or something? /me shrugs

We could use git instead of subversion. Just because there is cgit web interface which has a nice logo. See: http://git.archlinux.de/cgit.cgi PS: just kidding PPS: I would prefer WebSVN, too. -- archlinux.de

Jürgen Hötzel

10:46 p.m.

On Mon, Mar 31, 2008 at 04:22:05PM -0500, Aaron Griffin wrote:

...

It is a tad large, but SVN is nice in that it allows us to only check out subdirs we want, so you can checkout just your packages (see jason's archco tool[1])

I don't understand this point. I can do: cvs -d :ext:juergen@cvs.archlinux.org:/home/cvs-extra co extra/multimedia/mythtv extra/multimedia/mythmusic Jürgen

Aaron Griffin

11:13 p.m.

On Tue, Apr 1, 2008 at 1:46 PM, Jürgen Hötzel wrote:

...

On Mon, Mar 31, 2008 at 04:22:05PM -0500, Aaron Griffin wrote:

...
It is a tad large, but SVN is nice in that it allows us to only check out subdirs we want, so you can checkout just your packages (see jason's archco tool[1])

I don't understand this point. I can do:

cvs -d :ext:juergen@cvs.archlinux.org:/home/cvs-extra co extra/multimedia/mythtv extra/multimedia/mythmusic

I never asserted that CVS could not do so.

Aaron Griffin

3 Apr 3 Apr

6:54 p.m.

On Mon, Mar 31, 2008 at 4:22 PM, Aaron Griffin wrote:

...

So, what do I need from you? Nothing. I'm making this easy in that I will do all the work. I just need one thing: give me a day when it is best. When you all want to take a mini-vacation and do no packaging at all. If no one has a good day for this, I will probably do it on Thursday or Friday.

Ok, so. I need to fly out for a business trip tonight (anyone in Vegas today and tomorrow?). I was hoping to actually do this today, but that fell through. I will be back on Saturday, so I plan on doing this then, starting about 10am CST on Saturday. One request: Could you guys take a peek at the web-based viewers out there and let me know what you'd prefer? Items of interest: http://www.bluestatic.org/software/viewsvn/ http://www.viewvc.org/ http://websvn.tigris.org/ http://trac.edgewall.org/ I will be able to check email and all that, I'm not out of touch or anything - the flights just wreck my time. Cheers, Aaron

eliott

7:54 p.m.

On 4/3/08, Aaron Griffin wrote:

...

On Mon, Mar 31, 2008 at 4:22 PM, Aaron Griffin wrote:

...
So, what do I need from you? Nothing. I'm making this easy in that I will do all the work. I just need one thing: give me a day when it is best. When you all want to take a mini-vacation and do no packaging at all. If no one has a good day for this, I will probably do it on Thursday or Friday.

Ok, so. I need to fly out for a business trip tonight (anyone in Vegas today and tomorrow?). I was hoping to actually do this today, but that fell through. I will be back on Saturday, so I plan on doing this then, starting about 10am CST on Saturday.

One request: Could you guys take a peek at the web-based viewers out there and let me know what you'd prefer? Items of interest: http://www.bluestatic.org/software/viewsvn/ http://www.viewvc.org/ http://websvn.tigris.org/ http://trac.edgewall.org/

I don't think trac would be a good fit, as it does wiki and bugtracking too. I found some kind of comparison matrix. http://geekswithblogs.net/flanakin/articles/CompareSubversionWebTools.aspx

eliott

7:55 p.m.

...

I found some kind of comparison matrix. http://geekswithblogs.net/flanakin/articles/CompareSubversionWebTools.aspx

yikes. it sure it is an old article....

Thayer Williams

8:05 p.m.

On Apr 03, 2008 8:54 AM PDT, eliott wrote:

...

On 4/3/08, Aaron Griffin wrote:

...
On Mon, Mar 31, 2008 at 4:22 PM, Aaron Griffin wrote:

...
So, what do I need from you? Nothing. I'm making this easy in that I will do all the work. I just need one thing: give me a day when it is best. When you all want to take a mini-vacation and do no packaging at all. If no one has a good day for this, I will probably do it on Thursday or Friday.

Ok, so. I need to fly out for a business trip tonight (anyone in Vegas today and tomorrow?). I was hoping to actually do this today, but that fell through. I will be back on Saturday, so I plan on doing this then, starting about 10am CST on Saturday.

One request: Could you guys take a peek at the web-based viewers out there and let me know what you'd prefer? Items of interest: http://www.bluestatic.org/software/viewsvn/ http://www.viewvc.org/ http://websvn.tigris.org/ http://trac.edgewall.org/

I don't think trac would be a good fit, as it does wiki and bugtracking too.

I found some kind of comparison matrix. http://geekswithblogs.net/flanakin/articles/CompareSubversionWebTools.aspx

I don't have much experience with SVN, but since it's owned by tigris, one would think they would know how to best display it :) Then again, blue static's frontend has that oh-so-simple Mac approach; but is it as well-tested and maintained?

Travis Willard

8:54 p.m.

On Thu, Apr 3, 2008 at 11:54 AM, eliott wrote:

...

On 4/3/08, Aaron Griffin wrote:

...
On Mon, Mar 31, 2008 at 4:22 PM, Aaron Griffin wrote:

...
So, what do I need from you? Nothing. I'm making this easy in that I will do all the work. I just need one thing: give me a day when it is best. When you all want to take a mini-vacation and do no packaging at all. If no one has a good day for this, I will probably do it on Thursday or Friday.

Ok, so. I need to fly out for a business trip tonight (anyone in Vegas today and tomorrow?). I was hoping to actually do this today, but that fell through. I will be back on Saturday, so I plan on doing this then, starting about 10am CST on Saturday.

One request: Could you guys take a peek at the web-based viewers out there and let me know what you'd prefer? Items of interest: http://www.bluestatic.org/software/viewsvn/ http://www.viewvc.org/ http://websvn.tigris.org/ http://trac.edgewall.org/

I don't think trac would be a good fit, as it does wiki and bugtracking too.

I really haven't ever used anything other than ViewVC so I don't have a good basis for comparison. However, this brings up an interesting (if somewhat offtopic, sorry) point - if we used Trac, could we integrate our package bugtracking directly with our repo, so that the issue could associate itself with the package in SVN? Would that even be useful? There was talk about how flyspray sucked recently, IIRC, so this could be an integrated replacement. Additionally, I've been thinking of unified login stuff recently. Trac has a plugin for OpenID support[1], and punBB is looking to have a similar plugin in their 1.3 version[2], so it might be something to consider - OpenID seems to be gaining lots of traction. [1] http://trac-hacks.org/wiki/AuthOpenIdPlugin [2] http://punbb.org/forums/viewtopic.php?id=14983

Jason Chu

9:49 p.m.

On Thu, Apr 03, 2008 at 12:54:44PM -0400, Travis Willard wrote:

...

On Thu, Apr 3, 2008 at 11:54 AM, eliott wrote:

...
On 4/3/08, Aaron Griffin wrote:

...
On Mon, Mar 31, 2008 at 4:22 PM, Aaron Griffin wrote:

...
So, what do I need from you? Nothing. I'm making this easy in that I will do all the work. I just need one thing: give me a day when it is best. When you all want to take a mini-vacation and do no packaging at all. If no one has a good day for this, I will probably do it on Thursday or Friday.

Ok, so. I need to fly out for a business trip tonight (anyone in Vegas today and tomorrow?). I was hoping to actually do this today, but that fell through. I will be back on Saturday, so I plan on doing this then, starting about 10am CST on Saturday.

One request: Could you guys take a peek at the web-based viewers out there and let me know what you'd prefer? Items of interest: http://www.bluestatic.org/software/viewsvn/ http://www.viewvc.org/ http://websvn.tigris.org/ http://trac.edgewall.org/

I don't think trac would be a good fit, as it does wiki and bugtracking too.

I really haven't ever used anything other than ViewVC so I don't have a good basis for comparison.

However, this brings up an interesting (if somewhat offtopic, sorry) point - if we used Trac, could we integrate our package bugtracking directly with our repo, so that the issue could associate itself with the package in SVN? Would that even be useful? There was talk about how flyspray sucked recently, IIRC, so this could be an integrated replacement.

In general I'm not happy with Trac's wiki and bug tracker. Trac took all the simplest stuff and put it together so none of it is really good, it's just combined. Jason

Travis Willard

10:08 p.m.

On Thu, Apr 3, 2008 at 1:49 PM, Jason Chu wrote:

...

On Thu, Apr 03, 2008 at 12:54:44PM -0400, Travis Willard wrote:

...
On Thu, Apr 3, 2008 at 11:54 AM, eliott wrote:

...
On 4/3/08, Aaron Griffin wrote:

...
On Mon, Mar 31, 2008 at 4:22 PM, Aaron Griffin wrote:

...
So, what do I need from you? Nothing. I'm making this easy in that I will do all the work. I just need one thing: give me a day when it is best. When you all want to take a mini-vacation and do no packaging at all. If no one has a good day for this, I will probably do it on Thursday or Friday.

Ok, so. I need to fly out for a business trip tonight (anyone in Vegas today and tomorrow?). I was hoping to actually do this today, but that fell through. I will be back on Saturday, so I plan on doing this then, starting about 10am CST on Saturday.

One request: Could you guys take a peek at the web-based viewers out there and let me know what you'd prefer? Items of interest: http://www.bluestatic.org/software/viewsvn/ http://www.viewvc.org/ http://websvn.tigris.org/ http://trac.edgewall.org/

I don't think trac would be a good fit, as it does wiki and bugtracking too.

I really haven't ever used anything other than ViewVC so I don't have a good basis for comparison.

However, this brings up an interesting (if somewhat offtopic, sorry) point - if we used Trac, could we integrate our package bugtracking directly with our repo, so that the issue could associate itself with the package in SVN? Would that even be useful? There was talk about how flyspray sucked recently, IIRC, so this could be an integrated replacement.

In general I'm not happy with Trac's wiki and bug tracker. Trac took all the simplest stuff and put it together so none of it is really good, it's just combined.

Fair enough - glad to hear from someone with experience in the matter. I was just throwing it out there as a possibility. :)

Alexander Baldeck

4 Apr 4 Apr

1:02 p.m.

Jason Chu wrote:

...

In general I'm not happy with Trac's wiki and bug tracker. Trac took all the simplest stuff and put it together so none of it is really good, it's just combined.

Same here. In any way you can look at it, it will never outperform any specialized app instead of when it comes to number of features. Quantity over quality is trac. ;) On cvs.archlinuxppc.org I'm using viewvc ever since I've moved services. It's a little problematic to run it in a lighttpd environment but it works well, is stable and - what I find most convenient - looks and works the same way viewcvs did. viewvc +1 Cheers, Alex

Pierre Schmitz

3 Apr 3 Apr

8:17 p.m.

Am Donnerstag, 3. April 2008 16:54:39 schrieb Aaron Griffin:

...

Could you guys take a peek at the web-based viewers out there and let me know what you'd prefer?

I don't think web-based access is not a blocker. I would be fine with web_dav_svn for browsing the sources. If you think we need some more "bloat" we could start with websvn. If that does not fit our needs we could easily switch to another one later. Just a note: I think svn holdas an history for the whole repo, right? Is it still possible to get a log of just a directory? Think about "svn log http://svn.archlinux.org/core/base/kernel26"? -- archlinux.de

Pierre Schmitz

8:22 p.m.

Am Donnerstag, 3. April 2008 18:17:09 schrieb Pierre Schmitz:

...

Just a note: I think svn holdas an history for the whole repo, right? Is it still possible to get a log of just a directory? Think about "svn log http://svn.archlinux.org/core/base/kernel26"?

To answer myself: I just checked at KDE's svn and this is possible. :-) -- archlinux.de

Jason Chu

9:51 p.m.

On Thu, Apr 03, 2008 at 09:54:39AM -0500, Aaron Griffin wrote:

...

On Mon, Mar 31, 2008 at 4:22 PM, Aaron Griffin wrote:

...
So, what do I need from you? Nothing. I'm making this easy in that I will do all the work. I just need one thing: give me a day when it is best. When you all want to take a mini-vacation and do no packaging at all. If no one has a good day for this, I will probably do it on Thursday or Friday.

Ok, so. I need to fly out for a business trip tonight (anyone in Vegas today and tomorrow?). I was hoping to actually do this today, but that fell through. I will be back on Saturday, so I plan on doing this then, starting about 10am CST on Saturday.

One request: Could you guys take a peek at the web-based viewers out there and let me know what you'd prefer? Items of interest: http://www.bluestatic.org/software/viewsvn/ http://www.viewvc.org/ http://websvn.tigris.org/ http://trac.edgewall.org/

I've used websvn and trac. Websvn works just great and is fairly simple. I can't remember if there are any performance issues (things like creating lots of tarballs from directories and stuff). Jason

Thomas Bächler

5 Apr 5 Apr

12:12 p.m.

Aaron Griffin schrieb:

...

On Mon, Mar 31, 2008 at 4:22 PM, Aaron Griffin wrote:

...
So, what do I need from you? Nothing. I'm making this easy in that I will do all the work. I just need one thing: give me a day when it is best. When you all want to take a mini-vacation and do no packaging at all. If no one has a good day for this, I will probably do it on Thursday or Friday.

I feel guilty for not reading this thread until today. While I don't know what we will do to replace CVS's weird tagging mechanism, I will probably find it in an old thread. Really great something is finally happening, as CVS is annoying the crap out of me.

...

Ok, so. I need to fly out for a business trip tonight (anyone in Vegas today and tomorrow?). I was hoping to actually do this today, but that fell through. I will be back on Saturday, so I plan on doing this then, starting about 10am CST on Saturday.

Could you please say GMT+/-X instead of CST, because I have no idea what CST is. However, if you need help, I can probably assist you today.

eliott

12:27 p.m.

On 4/5/08, Thomas Bächler wrote:

...

Aaron Griffin schrieb:

...
On Mon, Mar 31, 2008 at 4:22 PM, Aaron Griffin wrote:

...
So, what do I need from you? Nothing. I'm making this easy in that I will do all the work. I just need one thing: give me a day when it is best. When you all want to take a mini-vacation and do no packaging at all. If no one has a good day for this, I will probably do it on Thursday or Friday.

I feel guilty for not reading this thread until today. While I don't know what we will do to replace CVS's weird tagging mechanism, I will probably find it in an old thread. Really great something is finally happening, as CVS is annoying the crap out of me.

...
Ok, so. I need to fly out for a business trip tonight (anyone in Vegas today and tomorrow?). I was hoping to actually do this today, but that fell through. I will be back on Saturday, so I plan on doing this then, starting about 10am CST on Saturday.

Could you please say GMT+/-X instead of CST, because I have no idea what CST is. However, if you need help, I can probably assist you today.

Actually it is CDT right now I believe. so... UTC - 5 hours http://www.timeanddate.com/library/abbreviations/timezones/na/cdt.html hooray for the added confusion of daylight savings time.

Aaron Griffin

9:25 p.m.

On Thu, Apr 3, 2008 at 9:54 AM, Aaron Griffin wrote:

...

I will be back on Saturday, so I plan on doing this then, starting about 10am CST on Saturday.

Due to some flight issues, I will not be home for another 5 hours or so. I will begin the conversion then. Jason, are you willing to commit the devtools changes to speed this up? The conversion itself should not take too long, as Jason made a neat little script to do it. Jason or Eliott, if you have the time and want to speed this up, could you possibly set the cvs repos to read-only. There is a conversion script in ~aaron/svnarch that you can run too, if you're feeling sassy. I'd like to mimic the cvs naming, so /home/cvs-extra == /home/svn-extra if someone does end up doing this. If not, I will get to it soon. I have a bit more time before my flight, but not enough to start this process right now. Feel free to contact me on jabber for the next 15mins or so

eliott

9:37 p.m.

On 4/5/08, Aaron Griffin wrote:

...

On Thu, Apr 3, 2008 at 9:54 AM, Aaron Griffin wrote:

...
I will be back on Saturday, so I plan on doing this then, starting about 10am CST on Saturday.

Due to some flight issues, I will not be home for another 5 hours or so. I will begin the conversion then.

Jason, are you willing to commit the devtools changes to speed this up?

The conversion itself should not take too long, as Jason made a neat little script to do it.

Jason or Eliott, if you have the time and want to speed this up, could you possibly set the cvs repos to read-only. There is a conversion script in ~aaron/svnarch that you can run too, if you're feeling sassy.

I'd like to mimic the cvs naming, so /home/cvs-extra == /home/svn-extra if someone does end up doing this.

ack! Any reason we couldn't consolidate at least one more dir down, to clean things up a bit? /home/repos/svn-core /home/repos/svn-extra

...

If not, I will get to it soon. I have a bit more time before my flight, but not enough to start this process right now. Feel free to contact me on jabber for the next 15mins or so

Jason Chu

9:54 p.m.

On Sat, Apr 05, 2008 at 10:37:00AM -0700, eliott wrote:

...

On 4/5/08, Aaron Griffin wrote:

...
On Thu, Apr 3, 2008 at 9:54 AM, Aaron Griffin wrote:

...
I will be back on Saturday, so I plan on doing this then, starting about 10am CST on Saturday.

Due to some flight issues, I will not be home for another 5 hours or so. I will begin the conversion then.

Jason, are you willing to commit the devtools changes to speed this up?

Yeah, I can make the devtools changes in git and have them ready to be packaged. If it's all the same to you, I'll push forward all the other patches in your devtools branch as well.

...

...
The conversion itself should not take too long, as Jason made a neat little script to do it.

Jason or Eliott, if you have the time and want to speed this up, could you possibly set the cvs repos to read-only. There is a conversion script in ~aaron/svnarch that you can run too, if you're feeling sassy.

I'd like to mimic the cvs naming, so /home/cvs-extra == /home/svn-extra if someone does end up doing this.

ack! Any reason we couldn't consolidate at least one more dir down, to clean things up a bit? /home/repos/svn-core /home/repos/svn-extra

Actually... the original idea was to have all of the repositories in one directory/repo... /home/repos/svn or somesuch. I don't know if Aaron changed his mind on that, but that ends up making the tagging a little weirder. Jason

Roman Kyrylych

6 Apr 6 Apr

11:20 a.m.

2008/4/5, Jason Chu :

...

On Sat, Apr 05, 2008 at 10:37:00AM -0700, eliott wrote:

...
On 4/5/08, Aaron Griffin wrote:

...
On Thu, Apr 3, 2008 at 9:54 AM, Aaron Griffin wrote:

...
I will be back on Saturday, so I plan on doing this then, starting about 10am CST on Saturday.

Due to some flight issues, I will not be home for another 5 hours or so. I will begin the conversion then.

Jason, are you willing to commit the devtools changes to speed this up?

Yeah, I can make the devtools changes in git and have them ready to be packaged. If it's all the same to you, I'll push forward all the other patches in your devtools branch as well.

...
...
The conversion itself should not take too long, as Jason made a neat little script to do it.

Jason or Eliott, if you have the time and want to speed this up, could you possibly set the cvs repos to read-only. There is a conversion script in ~aaron/svnarch that you can run too, if you're feeling sassy.

I'd like to mimic the cvs naming, so /home/cvs-extra == /home/svn-extra if someone does end up doing this.

ack! Any reason we couldn't consolidate at least one more dir down, to clean things up a bit? /home/repos/svn-core /home/repos/svn-extra

Actually... the original idea was to have all of the repositories in one directory/repo... /home/repos/svn or somesuch. I don't know if Aaron changed his mind on that, but that ends up making the tagging a little weirder.

Yeah, the directory structure was meant to be: /$pkgname/repos/extra/ /$pkgname/repos/extra-64/ /$pkgname/repos/testing/ /$pkgname/repos/testing-64/ /$pkgname/trunk/ I am confused with what Aaron wants to do now. :-/ The only thing I'd like to be different from the structure shown above is to use real arch suffixes instead of -64. So we'd get: /foo/extra-i686/ /bar/extra-any/ -- Roman Kyrylych (Роман Кирилич)

Roman Kyrylych

11:22 a.m.

2008/4/6, Roman Kyrylych :

...

2008/4/5, Jason Chu :

...
On Sat, Apr 05, 2008 at 10:37:00AM -0700, eliott wrote:

...
On 4/5/08, Aaron Griffin wrote:

...
I'd like to mimic the cvs naming, so /home/cvs-extra == /home/svn-extra if someone does end up doing this.

ack! Any reason we couldn't consolidate at least one more dir down, to clean things up a bit? /home/repos/svn-core /home/repos/svn-extra

Actually... the original idea was to have all of the repositories in one directory/repo... /home/repos/svn or somesuch. I don't know if Aaron changed his mind on that, but that ends up making the tagging a little weirder.

Yeah, the directory structure was meant to be: /$pkgname/repos/extra/ /$pkgname/repos/extra-64/ /$pkgname/repos/testing/ /$pkgname/repos/testing-64/ /$pkgname/trunk/ I am confused with what Aaron wants to do now. :-/ The only thing I'd like to be different from the structure shown above is to use real arch suffixes instead of -64. So we'd get: /foo/extra-i686/ /bar/extra-any/

err... this was meant to be: /foo/repos/extra-i686/ /bar/repos/extra-any/ of course -- Roman Kyrylych (Роман Кирилич)

Pierre Schmitz

11:25 a.m.

Am Sonntag, 6. April 2008 09:22:24 schrieb Roman Kyrylych:

...

err... this was meant to be: /foo/repos/extra-i686/ /bar/repos/extra-any/ of course

Have a look at gerolde; it allready looks like that :-) -- archlinux.de

Roman Kyrylych

11:28 a.m.

2008/4/6, Pierre Schmitz :

...

Am Sonntag, 6. April 2008 09:22:24 schrieb Roman Kyrylych:

...
err... this was meant to be: /foo/repos/extra-i686/ /bar/repos/extra-any/ of course

Have a look at gerolde; it allready looks like that :-)

aahhh!! /me tries to squeeze himself through a tough ssh channel to gerolde to see this asap. :-D -- Roman Kyrylych (Роман Кирилич)

Aaron Griffin

8 Apr 8 Apr

8:57 a.m.

On Sun, Apr 6, 2008 at 2:28 AM, Roman Kyrylych wrote:

...

2008/4/6, Pierre Schmitz :

...
Am Sonntag, 6. April 2008 09:22:24 schrieb Roman Kyrylych:

...
err... this was meant to be: /foo/repos/extra-i686/ /bar/repos/extra-any/ of course

Have a look at gerolde; it allready looks like that :-)

aahhh!! /me tries to squeeze himself through a tough ssh channel to gerolde to see this asap. :-D

Ok, bujeezus, I think I got the db scripts all sorted out. Sorry for the huge delay on this. Feel free to look over my changes. The initial commit is crap as reindented some files as I was making changes (whoops). http://projects.archlinux.org/git/?p=dbscripts.git;a=summary Now, keep in mind that when Eliott completes his DB parser, we can delete a bajillion of these files (omg woo!). And I do have some rewrites floating around here, so I may be tackling these within a few weeks. However, the next project is community. I didn't convert it here for two reasons: a) I didn't warn the TUs b) It's much bigger and has a big nast background daemon Please peek at these scripts, try running them (I only ran extra-i686 and it worked fine) Report anything and everything. I am currently looking into auto-killing dupes, but it's hard due to FORCE packages....

eliott

9:10 a.m.

wewt!

Aaron Griffin

9:44 a.m.

On Tue, Apr 8, 2008 at 12:10 AM, eliott wrote:

...

wewt!

I guess I forgot some explanation, huh? Jason covered most of it in the old thread, but I will regurgitate: The new devtools package (incoming soonish) contains a few real tiny tools. The first of these is "archco". You use it to checkout and update a single package. Now, you don't have to do this, but a full checkout takes some time... Anyway, say I run "archco openssh". I then cd openssh/trunk/, make the PKGBUILD edits, and commit them. The trunk, however, does nothing. It's just the master copy. Now what we do is run "archrelease core-i686". Alternatively, I can run "extrapkg" and it will do this step for me. So then the package is uploaded via extrapkg, and I run the db scripts as I used to. However, this time they take a tad longer. The svn export is a little more weighty than before. I may change it to use a permanent checkout per user (say at ~/.dbscripts/checkout or something) to make it much faster, but that's less important than actual functionality right now. Let me know if I got all this right, and I covered everything enough for you all.

Aaron Griffin

11:10 a.m.

On Tue, Apr 8, 2008 at 12:44 AM, Aaron Griffin wrote:

...

On Tue, Apr 8, 2008 at 12:10 AM, eliott wrote:

...
wewt!

I guess I forgot some explanation, huh?

Jason covered most of it in the old thread, but I will regurgitate:

The new devtools package (incoming soonish) contains a few real tiny tools. The first of these is "archco". You use it to checkout and update a single package. Now, you don't have to do this, but a full checkout takes some time...

Anyway, say I run "archco openssh". I then cd openssh/trunk/, make the PKGBUILD edits, and commit them. The trunk, however, does nothing. It's just the master copy. Now what we do is run "archrelease core-i686". Alternatively, I can run "extrapkg" and it will do this step for me.

So then the package is uploaded via extrapkg, and I run the db scripts as I used to. However, this time they take a tad longer. The svn export is a little more weighty than before. I may change it to use a permanent checkout per user (say at ~/.dbscripts/checkout or something) to make it much faster, but that's less important than actual functionality right now.

Let me know if I got all this right, and I covered everything enough for you all.

Caught a few bugs, the biggest one was on x86_64 (we killed off the "64" suffix on the staging dirs on accident). devtools 0.6.1 should be out soon-ish. If you happen to use 0.6.0 on x86_64, just know that the package was uploaded to staging/extra/add, and copy it to the right staging dir.

Thomas Bächler

11:20 a.m.

Aaron Griffin schrieb:

...

Caught a few bugs, the biggest one was on x86_64 (we killed off the "64" suffix on the staging dirs on accident). devtools 0.6.1 should be out soon-ish.

If you happen to use 0.6.0 on x86_64, just know that the package was uploaded to staging/extra/add, and copy it to the right staging dir.

I know I could probably look it up somewhere, but could someone give a quick summary (preferably as a top-posting on a new thread) on how things actually work now? On another note, when the web interface is adjusted, can we please get package information on both architectures? And we probably should clean it up somehow, there are some dead pages (for example device-mapper in testing, which isn't in testing any more).

Aaron Griffin

11:25 a.m.

On Tue, Apr 8, 2008 at 2:20 AM, Thomas Bächler wrote:

...

On another note, when the web interface is adjusted, can we please get package information on both architectures? And we probably should clean it up somehow, there are some dead pages (for example device-mapper in testing, which isn't in testing any more).

And we should probably do X and Y and Z. There's a hundred different things we COULD change at any given time. Right now the only person working on the backend is Eliott. The best way to handle these things is to put it on the bug tracker. Both Eliott and I seem to work best when there is a concise, itemized list of things to do. I made the "Internal Dev" section for a reason. Add the "device-mapper" thing there (I'm sure there's just a stale DB entry) and it should get fixed real quickly.

Thomas Bächler

11:32 a.m.

Aaron Griffin schrieb:

...

The best way to handle these things is to put it on the bug tracker. Both Eliott and I seem to work best when there is a concise, itemized list of things to do. I made the "Internal Dev" section for a reason.

Okay, however a task "add 64 bit info" is already open AFAIK.

...

Add the "device-mapper" thing there (I'm sure there's just a stale DB entry) and it should get fixed real quickly.

There are MANY stale DB entries, I discovered them by accident recently. And there are packages in core/extra with outdated information. I will see if I can find them, but I think the list is long.

Aaron Griffin

11:26 a.m.

On Tue, Apr 8, 2008 at 2:20 AM, Thomas Bächler wrote:

...

Aaron Griffin schrieb:

...
Caught a few bugs, the biggest one was on x86_64 (we killed off the "64" suffix on the staging dirs on accident). devtools 0.6.1 should be out soon-ish.

If you happen to use 0.6.0 on x86_64, just know that the package was uploaded to staging/extra/add, and copy it to the right staging dir.

I know I could probably look it up somewhere, but could someone give a quick summary (preferably as a top-posting on a new thread) on how things actually work now?

I just did... in fact it was the quoted text that you removed in your reply. http://archlinux.org/pipermail/arch-dev-public/2008-April/005650.html

Thomas Bächler

11:36 a.m.

Aaron Griffin schrieb:

...

I just did... in fact it was the quoted text that you removed in your reply.

http://archlinux.org/pipermail/arch-dev-public/2008-April/005650.html

I read that, I was talking about a quick overview about the actual layout of the SVN. Believe it or not, everybody seems to tell me something different about that. Is it pkgname/{trunk,repos/{i686,x86_64}} now (I vaguely remember that from an old discussion)? And you only mentioned how I can check out a single package, but I have no idea where I can check out the whole tree (which I'd like to have on my build machines). Posting an URL would be nice ...

Thomas Bächler

11:44 a.m.

Thomas Bächler schrieb:

...

I read that, I was talking about a quick overview about the actual layout of the SVN. Believe it or not, everybody seems to tell me something different about that. Is it pkgname/{trunk,repos/{i686,x86_64}} now (I vaguely remember that from an old discussion)?

And you only mentioned how I can check out a single package, but I have no idea where I can check out the whole tree (which I'd like to have on my build machines). Posting an URL would be nice ...

Nevermind, figured that all out. If nobody else does, I will post a "what works how" summary tonight, for future reference and for the ones among us who just don't have time to read all this.

Daniel Isenmann

7:55 p.m.

On Tue, 08 Apr 2008 09:44:03 +0200 Thomas Bächler wrote:

...

Thomas Bächler schrieb:

...
I read that, I was talking about a quick overview about the actual layout of the SVN. Believe it or not, everybody seems to tell me something different about that. Is it pkgname/{trunk,repos/{i686,x86_64}} now (I vaguely remember that from an old discussion)?

And you only mentioned how I can check out a single package, but I have no idea where I can check out the whole tree (which I'd like to have on my build machines). Posting an URL would be nice ...

Nevermind, figured that all out. If nobody else does, I will post a "what works how" summary tonight, for future reference and for the ones among us who just don't have time to read all this.

Thomas, would be great if you do this. I'm totally lost in the massive mails in this thread.... Thanks....Daniel

Eric Belanger

9:10 p.m.

On Tue, 8 Apr 2008, Daniel Isenmann wrote:

...

On Tue, 08 Apr 2008 09:44:03 +0200 Thomas Bächler wrote:

...
Thomas Bächler schrieb:

...
I read that, I was talking about a quick overview about the actual layout of the SVN. Believe it or not, everybody seems to tell me something different about that. Is it pkgname/{trunk,repos/{i686,x86_64}} now (I vaguely remember that from an old discussion)?

And you only mentioned how I can check out a single package, but I have no idea where I can check out the whole tree (which I'd like to have on my build machines). Posting an URL would be nice ...

Nevermind, figured that all out. If nobody else does, I will post a "what works how" summary tonight, for future reference and for the ones among us who just don't have time to read all this.

Thomas, would be great if you do this. I'm totally lost in the massive mails in this thread....

Thanks....Daniel

I agree. A quick how-to would be nice. Things I would like to know how to do with the new SVN repo: - how to checkout the whole repo and how to update it afterwards - how to add/remove files to the svn tree - how to add/remove packages from repos. Thanks. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.

Aaron Griffin

9:44 p.m.

On Tue, Apr 8, 2008 at 12:10 PM, Eric Belanger wrote:

...

Things I would like to know how to do with the new SVN repo: - how to checkout the whole repo and how to update it afterwards

I just want to say that this is not really recommended. The size on disk is huge (SVN keeps a copy of the HEAD revision in the .svn/ directory, so the overall size of the checkout is double that of the actual files). Feel free to do it, but I know I won't be doing it. Not to mention that fact that one individual package has copies in the repos/ dir too. A package in extra and testing for both architectures has 5 copies of the tracked files (and 5 more for the svn HEAD revisions). So that's a totaly of 10 PKGBUILDs and other files for one package. We have 2500ish last I checked. To checkout: svn co ssh://archlinux.org/home/svn-packages [optional directory name for checkout] To update later: cd <where you checked out the repo> svn up

...

- how to add/remove files to the svn tree

...

- how to add/remove packages from repos. This is all based on the packagename/repos/ directory (this takes the

svn add myfile svn rm myfile place of our CVS tags). These tags are of the form repos/$reponame-$arch. So, repos/extra-i686 means it is in extra for the i686 architecture. Here's an example: $ archco openssh A openssh/trunk A openssh/trunk/PKGBUILD A openssh/trunk/sshd A openssh/trunk/sshd.confd A openssh/trunk/sshd.pam A openssh/repos A openssh/repos/core-i686 A openssh/repos/core-i686/PKGBUILD A openssh/repos/core-i686/sshd A openssh/repos/core-i686/sshd.confd A openssh/repos/core-i686/sshd.pam A openssh/repos/core-x86_64 A openssh/repos/core-x86_64/PKGBUILD A openssh/repos/core-x86_64/sshd A openssh/repos/core-x86_64/sshd.confd A openssh/repos/core-x86_64/sshd.pam A openssh/repos/testing-i686 A openssh/repos/testing-i686/PKGBUILD A openssh/repos/testing-i686/sshd A openssh/repos/testing-i686/sshd.confd A openssh/repos/testing-i686/sshd.pam Checked out revision 21. Notice that openssh is in core-i686, core-x86_64, and testing-i686. These are actual svn copies, which means they are, in effect, branches or the trunk PKGBUILD. That means that you *can* edit them differently if you so wish, but it's probably a better idea to edit only the trunk/ PKGBUILD. So, now I'm building openssh for testing-x86_64. I cd into the trunk, run makepkg. Same old, same old. When this is complete, I namcap and all that fun stuff. Then I let archrelease do it's magic - it handles all the svn copying and all that stuff (bash script, go ahead and peek at it). archrelease is called by testingpkg - no extra steps. Just run testingpkg, it will call archrelease, and upload the package Now if I re-run archco for openssh, I will get some extra files: A openssh/repos/testing-i686 A openssh/repos/testing-i686/PKGBUILD A openssh/repos/testing-i686/sshd A openssh/repos/testing-i686/sshd.confd A openssh/repos/testing-i686/sshd.pam Now I ssh to gerolde like normal and run the exact same scripts. Viola. PS I just did openssh for x86_64 as I was writing this 8)

Aaron Griffin

9:49 p.m.

On Tue, Apr 8, 2008 at 12:44 PM, Aaron Griffin wrote:

...

Now if I re-run archco for openssh, I will get some extra files: A openssh/repos/testing-i686 A openssh/repos/testing-i686/PKGBUILD A openssh/repos/testing-i686/sshd A openssh/repos/testing-i686/sshd.confd A openssh/repos/testing-i686/sshd.pam

Whoops, copied the wrong ones... not that it matters, I'm sure you got the point A openssh/repos/testing-x86_64 A openssh/repos/testing-x86_64/PKGBUILD A openssh/repos/testing-x86_64/sshd A openssh/repos/testing-x86_64/sshd.confd A openssh/repos/testing-x86_64/sshd.pam

Aaron Griffin

10:44 p.m.

On Tue, Apr 8, 2008 at 12:49 PM, Aaron Griffin wrote:

...

On Tue, Apr 8, 2008 at 12:44 PM, Aaron Griffin wrote:

...
Now if I re-run archco for openssh, I will get some extra files: A openssh/repos/testing-i686 A openssh/repos/testing-i686/PKGBUILD A openssh/repos/testing-i686/sshd A openssh/repos/testing-i686/sshd.confd A openssh/repos/testing-i686/sshd.pam

Whoops, copied the wrong ones... not that it matters, I'm sure you got the point

A openssh/repos/testing-x86_64 A openssh/repos/testing-x86_64/PKGBUILD A openssh/repos/testing-x86_64/sshd A openssh/repos/testing-x86_64/sshd.confd A openssh/repos/testing-x86_64/sshd.pam

There was a question about moving something from testing to extra. Originally, the package was submitted with "testingpkg" which creates pkgname/repos/testing-$arch and uploads. Now, to release to extra, we run extrapkg to create pkgname/repos/extra-$arch and upload. Easy as pie. Removing from testing would be as simple as: svn rm -f pkgname/repos/testing-$arch Now.... head's up: I will be partially implementing the move on the dbscripts side. That is, if a package being uploaded to extra is in testing, it will do all the removal from the DB and that fun stuff... I don't know if I will remove it from svn or not, but I always could...

Travis Willard

10:56 p.m.

On Tue, Apr 8, 2008 at 2:44 PM, Aaron Griffin wrote:

...

On Tue, Apr 8, 2008 at 12:49 PM, Aaron Griffin wrote:

...
On Tue, Apr 8, 2008 at 12:44 PM, Aaron Griffin wrote:

...
Now if I re-run archco for openssh, I will get some extra files: A openssh/repos/testing-i686 A openssh/repos/testing-i686/PKGBUILD A openssh/repos/testing-i686/sshd A openssh/repos/testing-i686/sshd.confd A openssh/repos/testing-i686/sshd.pam

Whoops, copied the wrong ones... not that it matters, I'm sure you got the point

A openssh/repos/testing-x86_64 A openssh/repos/testing-x86_64/PKGBUILD A openssh/repos/testing-x86_64/sshd A openssh/repos/testing-x86_64/sshd.confd A openssh/repos/testing-x86_64/sshd.pam

There was a question about moving something from testing to extra.

Originally, the package was submitted with "testingpkg" which creates pkgname/repos/testing-$arch and uploads. Now, to release to extra, we run extrapkg to create pkgname/repos/extra-$arch and upload. Easy as pie.

Removing from testing would be as simple as: svn rm -f pkgname/repos/testing-$arch

Now.... head's up: I will be partially implementing the move on the dbscripts side. That is, if a package being uploaded to extra is in testing, it will do all the removal from the DB and that fun stuff... I don't know if I will remove it from svn or not, but I always could...

Hm.. that's a tough call. Ideally, if you're removing it from the DB on gerolde, it should be removed from svn too - svn's repos/* folders should match *exactly* what's in the repo - any automation should take that into account, IMO. Also, thanks a TON for the work that went into this Aaron (and anyone who helped Aaron) - I think this is a huge step for us, and getting it done so quickly and so well is awesome. Again, thanks a million.

Pierre Schmitz

11:04 p.m.

Am Dienstag, 8. April 2008 20:44:38 schrieb Aaron Griffin:

...

There was a question about moving something from testing to extra.

Originally, the package was submitted with "testingpkg" which creates pkgname/repos/testing-$arch and uploads. Now, to release to extra, we run extrapkg to create pkgname/repos/extra-$arch and upload. Easy as pie.

Removing from testing would be as simple as: svn rm -f pkgname/repos/testing-$arch

Now.... head's up: I will be partially implementing the move on the dbscripts side. That is, if a package being uploaded to extra is in testing, it will do all the removal from the DB and that fun stuff... I don't know if I will remove it from svn or not, but I always could...

No idea if I got this right, but this way we have to upload the package twice? (OK, if this is the case I could update my testing2extra script which runs on gerolde anyway; so in fact it would be a local copy) -- archlinux.de

Jason Chu

9 Apr 9 Apr

1:17 a.m.

On Tue, Apr 08, 2008 at 09:04:44PM +0200, Pierre Schmitz wrote:

...

Am Dienstag, 8. April 2008 20:44:38 schrieb Aaron Griffin:

...
There was a question about moving something from testing to extra.

Originally, the package was submitted with "testingpkg" which creates pkgname/repos/testing-$arch and uploads. Now, to release to extra, we run extrapkg to create pkgname/repos/extra-$arch and upload. Easy as pie.

Removing from testing would be as simple as: svn rm -f pkgname/repos/testing-$arch

Now.... head's up: I will be partially implementing the move on the dbscripts side. That is, if a package being uploaded to extra is in testing, it will do all the removal from the DB and that fun stuff... I don't know if I will remove it from svn or not, but I always could...

No idea if I got this right, but this way we have to upload the package twice? (OK, if this is the case I could update my testing2extra script which runs on gerolde anyway; so in fact it would be a local copy)

Oh, I see what you're saying. I'll make an amendment to Aaron's comment. If you're moving a package from testing to extra, usually an "archrelease extra" is all you need from the trunk directory. You do *not* need to upload the package again. Jason

Pierre Schmitz

1:26 a.m.

Am Dienstag, 8. April 2008 23:17:38 schrieb Jason Chu:

...

If you're moving a package from testing to extra, usually an "archrelease extra" is all you need from the trunk directory. You do *not* need to upload the package again.

So the package itself is moved by the db-scritps then? And there is no need to move arround file in /home/ftp manually or put anything in our staging dirs? -- archlinux.de

Jason Chu

1:44 a.m.

On Tue, Apr 08, 2008 at 11:26:58PM +0200, Pierre Schmitz wrote:

...

Am Dienstag, 8. April 2008 23:17:38 schrieb Jason Chu:

...
If you're moving a package from testing to extra, usually an "archrelease extra" is all you need from the trunk directory. You do *not* need to upload the package again.

So the package itself is moved by the db-scritps then? And there is no need to move arround file in /home/ftp manually or put anything in our staging dirs?

It all depends on how testing2extra does it. /arch/db-extra definitely won't do it. Basically, everything from the db repo forward is all the same. The difference is how the PKGBUILDs are stored and kept track of. I don't know how to explain it without getting all wordy. I'm interested in what Thomas has to write so that I can clarify things and give more information as people need to learn more. Jason

Thomas Bächler

2:16 a.m.

Jason Chu schrieb:

...

I don't know how to explain it without getting all wordy. I'm interested in what Thomas has to write so that I can clarify things and give more information as people need to learn more.

Yeah, had to postpone that mail, sorry :)

Aaron Griffin

2:05 a.m.

On Tue, Apr 8, 2008 at 4:26 PM, Pierre Schmitz wrote:

...

Am Dienstag, 8. April 2008 23:17:38 schrieb Jason Chu:

...
If you're moving a package from testing to extra, usually an "archrelease extra" is all you need from the trunk directory. You do *not* need to upload the package again.

So the package itself is moved by the db-scritps then? And there is no need to move arround file in /home/ftp manually or put anything in our staging dirs?

No no, nothing is actually done yet. Everything else is exactly the same as it always has been. For reference: http://archlinux.org/pipermail/arch-dev-public/2008-February/004556.html What I am _planning_ on doing is do it all this way: New package in non-testing repo Package is in testing, and vercmp says it's older Delete SVN entry for testing Remove from testing DB Delete package file All this would be part of running the DB scripts on gerolde but it is not done yet. Right now it is exactly the same process as it has always been

Eric Belanger

15 Apr 15 Apr

6:40 a.m.

On Tue, 8 Apr 2008, Jason Chu wrote:

...

On Tue, Apr 08, 2008 at 09:04:44PM +0200, Pierre Schmitz wrote:

...
Am Dienstag, 8. April 2008 20:44:38 schrieb Aaron Griffin:

...
There was a question about moving something from testing to extra.

Originally, the package was submitted with "testingpkg" which creates pkgname/repos/testing-$arch and uploads. Now, to release to extra, we run extrapkg to create pkgname/repos/extra-$arch and upload. Easy as pie.

Removing from testing would be as simple as: svn rm -f pkgname/repos/testing-$arch

Now.... head's up: I will be partially implementing the move on the dbscripts side. That is, if a package being uploaded to extra is in testing, it will do all the removal from the DB and that fun stuff... I don't know if I will remove it from svn or not, but I always could...

No idea if I got this right, but this way we have to upload the package twice? (OK, if this is the case I could update my testing2extra script which runs on gerolde anyway; so in fact it would be a local copy)

Oh, I see what you're saying. I'll make an amendment to Aaron's comment. If you're moving a package from testing to extra, usually an "archrelease extra" is all you need from the trunk directory. You do *not* need to upload the package again.

Jason

...

From the output there was no error but the package is not in the repo. This has happened a couple of time. Am I trying to update packages that have already been uploaded to another dev staging dir? Or is there another

I tried to move bmpx from testing to extra but it doesn't work. First, the '-f' switch doesn't it's '--force'. I ran 'archrelease extra' in the trunk directory then did the package move and db-script on gerolde but it only removed the testing package. The package in extra is still at the old version. It seems that the command should be 'archrelease extra-$arch'. Is that correct? I tried that then ran the db-script after copying the package to my staging dir but it doesn't work. Can someone fix this and clarify the process? I also tried to update firefox3 for unstable x86_64. When running unstablepkg I got: $ unstablepkg firefox3-3.0b5-1-x86_64.pkg.tar.gz 100% 11MB 91.1KB/s 02:03 File integrity okay. ===> Uploaded firefox3-3.0b5-1-x86_64.pkg.tar.gz ===> Commited with "upgpkg: firefox3 3.0b5-1" message ~/svnroot/firefox3 ~/svnroot/firefox3/trunk Nothing to commit ~/svnroot/firefox3/trunk ===> Tagged for unstable-x86_64 The package was uploaded to my staging directory and I ran the db script. problem. Thanks. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.

Dan McGee

8 Apr 8 Apr

11:14 p.m.

On Tue, Apr 8, 2008 at 12:44 PM, Aaron Griffin wrote:

...

On Tue, Apr 8, 2008 at 12:10 PM, Eric Belanger wrote:

...
Things I would like to know how to do with the new SVN repo: - how to checkout the whole repo and how to update it afterwards

I just want to say that this is not really recommended. The size on disk is huge (SVN keeps a copy of the HEAD revision in the .svn/ directory, so the overall size of the checkout is double that of the actual files). Feel free to do it, but I know I won't be doing it.

Not to mention that fact that one individual package has copies in the repos/ dir too. A package in extra and testing for both architectures has 5 copies of the tracked files (and 5 more for the svn HEAD revisions). So that's a totaly of 10 PKGBUILDs and other files for one package. We have 2500ish last I checked.

Damn, this kind of sucks. I've always liked the fact that I can get all of the content of the Arch repos locally without it being a pain in the ass- it is really nice to be able to search through every PKGBUILD for instance for broken licenses, etc. Does SVN have some sort of exclusion feature that can be used when checking out to only get folders that look like */trunk/* for instance? Another quick question- say we have libfoo-3.0.0 in testing, which needs to sit there for rebuilds, but a critical security fix in libfoo-2.5.7 comes out (and we currently have 2.5.6 in extra). Can our dbscripts and devtools handle this case where I actually DO want to edit the non-trunk PKGBUILD? -Dan

Jason Chu

9 Apr 9 Apr

1:15 a.m.

On Tue, Apr 08, 2008 at 02:14:57PM -0500, Dan McGee wrote:

...

On Tue, Apr 8, 2008 at 12:44 PM, Aaron Griffin wrote:

...
On Tue, Apr 8, 2008 at 12:10 PM, Eric Belanger wrote:

...
Things I would like to know how to do with the new SVN repo: - how to checkout the whole repo and how to update it afterwards

I just want to say that this is not really recommended. The size on disk is huge (SVN keeps a copy of the HEAD revision in the .svn/ directory, so the overall size of the checkout is double that of the actual files). Feel free to do it, but I know I won't be doing it.

Not to mention that fact that one individual package has copies in the repos/ dir too. A package in extra and testing for both architectures has 5 copies of the tracked files (and 5 more for the svn HEAD revisions). So that's a totaly of 10 PKGBUILDs and other files for one package. We have 2500ish last I checked.

Damn, this kind of sucks. I've always liked the fact that I can get all of the content of the Arch repos locally without it being a pain in the ass- it is really nice to be able to search through every PKGBUILD for instance for broken licenses, etc. Does SVN have some sort of exclusion feature that can be used when checking out to only get folders that look like */trunk/* for instance?

I'm not sure that svn can, but it's possible svk could. Either way, actual merges between trunk and repos/ would *have* to be done by svnmerge. Abs will still be laid out the same way and also be a really good way to grep through all the PKGBUILDs for random data.

...

Another quick question- say we have libfoo-3.0.0 in testing, which needs to sit there for rebuilds, but a critical security fix in libfoo-2.5.7 comes out (and we currently have 2.5.6 in extra). Can our dbscripts and devtools handle this case where I actually DO want to edit the non-trunk PKGBUILD?

This was one of the main design decisions. Multiple versions can be tracked at any time (I like to call the feature "actual branches"). The archrelease script really just uses svnmerge to merge changes from trunk to repos/. svnmerge is the key that makes this all work. That's why I'm stressing that we have to use it so much. svnmerge is able to look at two paths and ask the question, "which changes haven't been merged yet?" If we merge changes from trunk to repos/ without using svnmerge, it won't know about them and it'll try to merge them again. If there is a case where svnmerge is confused because something was done in a different way, it is possible to fix. I just don't want people making those sorts of changes and making me clean up the mess ;) Jason

Eric Belanger

10:09 p.m.

On Tue, 8 Apr 2008, Aaron Griffin wrote:

...

On Tue, Apr 8, 2008 at 12:10 PM, Eric Belanger wrote:

...
Things I would like to know how to do with the new SVN repo: - how to checkout the whole repo and how to update it afterwards

I just want to say that this is not really recommended. The size on disk is huge (SVN keeps a copy of the HEAD revision in the .svn/ directory, so the overall size of the checkout is double that of the actual files). Feel free to do it, but I know I won't be doing it.

Not to mention that fact that one individual package has copies in the repos/ dir too. A package in extra and testing for both architectures has 5 copies of the tracked files (and 5 more for the svn HEAD revisions). So that's a totaly of 10 PKGBUILDs and other files for one package. We have 2500ish last I checked.

Thanks for the explanation. I wasn't aware that it had that much overhead. I'll probably just checkout what I need with archco. One more thing: with cvs we had to export the CVSROOT variable on our local machine. Is a similar step required with the new svn setup or is everything taken care in archco? I'm not at my Arch machine right now so I can't check it. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.

Travis Willard

10:29 p.m.

On Wed, Apr 9, 2008 at 2:09 PM, Eric Belanger wrote:

...

On Tue, 8 Apr 2008, Aaron Griffin wrote:

...
On Tue, Apr 8, 2008 at 12:10 PM, Eric Belanger wrote:

...
Things I would like to know how to do with the new SVN repo: - how to checkout the whole repo and how to update it afterwards

I just want to say that this is not really recommended. The size on disk is huge (SVN keeps a copy of the HEAD revision in the .svn/ directory, so the overall size of the checkout is double that of the actual files). Feel free to do it, but I know I won't be doing it.

Not to mention that fact that one individual package has copies in the repos/ dir too. A package in extra and testing for both architectures has 5 copies of the tracked files (and 5 more for the svn HEAD revisions). So that's a totaly of 10 PKGBUILDs and other files for one package. We have 2500ish last I checked.

Thanks for the explanation. I wasn't aware that it had that much overhead. I'll probably just checkout what I need with archco.

One more thing: with cvs we had to export the CVSROOT variable on our local machine. Is a similar step required with the new svn setup or is everything taken care in archco? I'm not at my Arch machine right now so I can't check it.

Everything is taken care of in archco - I ran it on a couple of my packages last night and it worked fine

Eric Belanger

14 Apr 14 Apr

10:17 a.m.

On Wed, 9 Apr 2008, Travis Willard wrote:

...

On Wed, Apr 9, 2008 at 2:09 PM, Eric Belanger wrote:

...
On Tue, 8 Apr 2008, Aaron Griffin wrote:

...
On Tue, Apr 8, 2008 at 12:10 PM, Eric Belanger wrote:

...
Things I would like to know how to do with the new SVN repo: - how to checkout the whole repo and how to update it afterwards

I just want to say that this is not really recommended. The size on disk is huge (SVN keeps a copy of the HEAD revision in the .svn/ directory, so the overall size of the checkout is double that of the actual files). Feel free to do it, but I know I won't be doing it.

Not to mention that fact that one individual package has copies in the repos/ dir too. A package in extra and testing for both architectures has 5 copies of the tracked files (and 5 more for the svn HEAD revisions). So that's a totaly of 10 PKGBUILDs and other files for one package. We have 2500ish last I checked.

Thanks for the explanation. I wasn't aware that it had that much overhead. I'll probably just checkout what I need with archco.

One more thing: with cvs we had to export the CVSROOT variable on our local machine. Is a similar step required with the new svn setup or is everything taken care in archco? I'm not at my Arch machine right now so I can't check it.

Everything is taken care of in archco - I ran it on a couple of my packages last night and it worked fine

Another question: How do we add packages to the repo? I need to moved a couple packages from unsupported to extra (new depends for gimp-devel). Thanks. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.

Aaron Griffin

6:59 p.m.

On Mon, Apr 14, 2008 at 1:17 AM, Eric Belanger wrote:

...

Another question: How do we add packages to the repo? I need to moved a couple packages from unsupported to extra (new depends for gimp-devel).

Hrm, good question 8) You could checkout the full repo... but Jason had a good idea that we might want to integrate into archco: svn checkout -N svn+ssh://archlinux.org/home/svn-packages/ The -N makes it non-recursive... so you don't get any directories... from there you can actually just do something like: cd svn-packages svn checkout xine-lib This might be a little better than using archco, and lets us do lots more.

...

From here you should be able to just "svn add" anything.

Opinions?

Travis Willard

7:04 p.m.

On Mon, Apr 14, 2008 at 10:59 AM, Aaron Griffin wrote:

...

On Mon, Apr 14, 2008 at 1:17 AM, Eric Belanger

wrote:

...
Another question: How do we add packages to the repo? I need to moved a couple packages from unsupported to extra (new depends for gimp-devel).

Hrm, good question 8)

You could checkout the full repo... but Jason had a good idea that we might want to integrate into archco:

svn checkout -N svn+ssh://archlinux.org/home/svn-packages/

The -N makes it non-recursive... so you don't get any directories... from there you can actually just do something like:

cd svn-packages svn checkout xine-lib

This might be a little better than using archco, and lets us do lots more.

...
From here you should be able to just "svn add" anything.

Opinions?

Hm - that's a neat idea. Then adding totally-new packages becomes easy.

Dan McGee

11:51 p.m.

On Mon, Apr 14, 2008 at 9:59 AM, Aaron Griffin wrote:

...

On Mon, Apr 14, 2008 at 1:17 AM, Eric Belanger

wrote:

...
Another question: How do we add packages to the repo? I need to moved a couple packages from unsupported to extra (new depends for gimp-devel).

Hrm, good question 8)

You could checkout the full repo... but Jason had a good idea that we might want to integrate into archco:

svn checkout -N svn+ssh://archlinux.org/home/svn-packages/

The -N makes it non-recursive... so you don't get any directories... from there you can actually just do something like:

cd svn-packages svn checkout xine-lib

This might be a little better than using archco, and lets us do lots more.

...
From here you should be able to just "svn add" anything.

Opinions?

+1. This seems to make a lot of sense. I'll let you guys work out the integration details. :P -Dan

Aaron Griffin

15 Apr 15 Apr

12:40 a.m.

Just clarifying something I said: On Mon, Apr 14, 2008 at 2:51 PM, Dan McGee wrote:

...

On Mon, Apr 14, 2008 at 9:59 AM, Aaron Griffin wrote:

...
svn checkout -N svn+ssh://archlinux.org/home/svn-packages/

The -N makes it non-recursive... so you don't get any directories... from there you can actually just do something like:

cd svn-packages svn checkout xine-lib

This might be a little better than using archco, and lets us do lots more.

This needs to be: cd svn-packages svn update xine-lib

...

+1. This seems to make a lot of sense. I'll let you guys work out the integration details. :P

Aye. I'll cobble it together when I finish some DB script overhauling. For now, the above doesn't seem too cryptic to me

Eric Belanger

18 Apr 18 Apr

5:29 a.m.

On Mon, 14 Apr 2008, Aaron Griffin wrote:

...

On Mon, Apr 14, 2008 at 1:17 AM, Eric Belanger wrote:

...
Another question: How do we add packages to the repo? I need to moved a couple packages from unsupported to extra (new depends for gimp-devel).

Hrm, good question 8)

You could checkout the full repo... but Jason had a good idea that we might want to integrate into archco:

svn checkout -N svn+ssh://archlinux.org/home/svn-packages/

The -N makes it non-recursive... so you don't get any directories... from there you can actually just do something like:

cd svn-packages svn checkout xine-lib

This might be a little better than using archco, and lets us do lots more.

...
From here you should be able to just "svn add" anything.

Opinions?

Do I need to also add the trunk and repo directories or will they be created automatically? For example, I want to add babl to extra, so I do: svn checkout -N svn+ssh://archlinux.org/home/svn-packages/ cd svn-packages svn add babl Is that all or does it needs other steps? I just want to make sure I get it right before going ahead. Thanks Eric -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.

Dan McGee

5:58 a.m.

On Thu, Apr 17, 2008 at 8:29 PM, Eric Belanger wrote:

...

On Mon, 14 Apr 2008, Aaron Griffin wrote:

...
On Mon, Apr 14, 2008 at 1:17 AM, Eric Belanger wrote:

...
Another question: How do we add packages to the repo? I need to moved a couple packages from unsupported to extra (new depends for gimp-devel).

Hrm, good question 8)

You could checkout the full repo... but Jason had a good idea that we might want to integrate into archco:

svn checkout -N svn+ssh://archlinux.org/home/svn-packages/

The -N makes it non-recursive... so you don't get any directories... from there you can actually just do something like:

cd svn-packages svn checkout xine-lib

This might be a little better than using archco, and lets us do lots more.

...
From here you should be able to just "svn add" anything.

Opinions?

Do I need to also add the trunk and repo directories or will they be created automatically? For example, I want to add babl to extra, so I do:

svn checkout -N svn+ssh://archlinux.org/home/svn-packages/ cd svn-packages svn add babl

Is that all or does it needs other steps? I just want to make sure I get it right before going ahead.

You'll need to put your stuff in the trunk directory, but from there running the tools should make the proper moves to the repo-arch dirs. -Dan

Eric Belanger

6:01 a.m.

On Thu, 17 Apr 2008, Dan McGee wrote:

...

On Thu, Apr 17, 2008 at 8:29 PM, Eric Belanger wrote:

...
On Mon, 14 Apr 2008, Aaron Griffin wrote:

...
On Mon, Apr 14, 2008 at 1:17 AM, Eric Belanger wrote:

...
Another question: How do we add packages to the repo? I need to moved a couple packages from unsupported to extra (new depends for gimp-devel).

Hrm, good question 8)

You could checkout the full repo... but Jason had a good idea that we might want to integrate into archco:

svn checkout -N svn+ssh://archlinux.org/home/svn-packages/

The -N makes it non-recursive... so you don't get any directories... from there you can actually just do something like:

cd svn-packages svn checkout xine-lib

This might be a little better than using archco, and lets us do lots more.

...
From here you should be able to just "svn add" anything.

Opinions?

Do I need to also add the trunk and repo directories or will they be created automatically? For example, I want to add babl to extra, so I do:

svn checkout -N svn+ssh://archlinux.org/home/svn-packages/ cd svn-packages svn add babl

Is that all or does it needs other steps? I just want to make sure I get it right before going ahead.

You'll need to put your stuff in the trunk directory, but from there running the tools should make the proper moves to the repo-arch dirs.

-Dan

Do I need to: cd babl svn add trunk before? -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.

eliott

9:07 a.m.

...

You'll need to put your stuff in the trunk directory, but from there running the tools should make the proper moves to the repo-arch dirs.

That made me think of "more junk in the trunk". For the record, I laughed hard.

Eric Belanger

19 Apr 19 Apr

12:25 a.m.

On Thu, 17 Apr 2008, Dan McGee wrote:

...

On Thu, Apr 17, 2008 at 8:29 PM, Eric Belanger wrote:

...
On Mon, 14 Apr 2008, Aaron Griffin wrote:

...
On Mon, Apr 14, 2008 at 1:17 AM, Eric Belanger wrote:

...
Another question: How do we add packages to the repo? I need to moved a couple packages from unsupported to extra (new depends for gimp-devel).

Hrm, good question 8)

You could checkout the full repo... but Jason had a good idea that we might want to integrate into archco:

svn checkout -N svn+ssh://archlinux.org/home/svn-packages/

The -N makes it non-recursive... so you don't get any directories... from there you can actually just do something like:

cd svn-packages svn checkout xine-lib

This might be a little better than using archco, and lets us do lots more.

...
From here you should be able to just "svn add" anything.

Opinions?

Do I need to also add the trunk and repo directories or will they be created automatically? For example, I want to add babl to extra, so I do:

svn checkout -N svn+ssh://archlinux.org/home/svn-packages/ cd svn-packages svn add babl

Is that all or does it needs other steps? I just want to make sure I get it right before going ahead.

You'll need to put your stuff in the trunk directory, but from there running the tools should make the proper moves to the repo-arch dirs.

-Dan

After a couple of errors, I successfully added babl to extra. Here's the missing steps I had to do to make it work. $ svn checkout -N svn+ssh://archlinux.org/home/svn-packages/ $ cd svn-packages $ mkdir babl $ svn add babl $ svn commit If you don't 'svn commit' here you'll get this error: $ extrapkg "Added to [extra] repo" babl-0.0.20-1-x86_64.pkg.tar.gz 100% 79KB 79.5KB/s 00:00 File integrity okay. ===> Uploaded babl-0.0.20-1-x86_64.pkg.tar.gz svn: Commit failed (details follow): svn: '/home/eric/svnroot/svn-packages/babl' is not under version control and is not part of the commit, yet its child '/home/eric/svnroot/svn -packages/babl/trunk' is part of the commit Cancelled Then we do: $ cd babl $ mkdir trunk repos $ svn add trunk repos $ svn commit I'm not sure if this 'svn commit' is necessary but you also need to create the repos dir otherwise you get this error: $ extrapkg "Added to [extra] repo" babl-0.0.20-1-x86_64.pkg.tar.gz 100% 79KB 79.5KB/s 00:00 File integrity okay. ===> Uploaded babl-0.0.20-1-x86_64.pkg.tar.gz ===> Commited with "upgpkg: babl 0.0.20-1 Added to [extra] repo" message ~/svnroot/svn-packages/babl ~/svnroot/svn-packages/babl/trunk svn: Path 'repos' is not a directory /usr/bin/archrelease: line 12: pushd: repos/extra-x86_64: No such file or directory svnmerge: no copyfrom info available. Explicit head argument (-S/--head) required. svn: Can't open file 'svnmerge-commit-message.txt': No such file or directory rm: cannot remove `svnmerge-commit-message.txt': No such file or directory ~/svnroot/svn-packages/babl/trunk /usr/bin/archrelease: line 17: popd: directory stack empty Cancelled Not sure if archrelease can be fixe to add the repos dir if missing. After, it's the usual: cd trunk then copy the PKGBUILD and other build files, 'svn add' them, copy package in trunk then run extrapkg. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.

Aaron Griffin

8 Apr 8 Apr

8 p.m.

On Tue, Apr 8, 2008 at 2:44 AM, Thomas Bächler wrote:

...

Nevermind, figured that all out. If nobody else does, I will post a "what works how" summary tonight, for future reference and for the ones among us who just don't have time to read all this.

Yeah, the repo is at /home/svn-packages, and you can check it out over ssh (eventually authz?). Let me know if you have any other questions, but the process outlined in an earlier email (archco pkgname, modify, commit, extrapkg) should be pretty much all you need

Thomas Bächler

8:12 p.m.

Aaron Griffin schrieb:

...

Yeah, the repo is at /home/svn-packages, and you can check it out over ssh (eventually authz?).

Found that by reading archco.

...

Let me know if you have any other questions, but the process outlined in an earlier email (archco pkgname, modify, commit, extrapkg) should be pretty much all you need

It's not about what I need, it's about understanding the process. By reading the new extrapkg, I am able to find it all out. As requested by Daniel, I will outline the whole thing in a short summary, for those who are "lost" in the chaos of change (not everyone spent the last few days on this topic as you did). Time to go home first!

Aaron Griffin

8:18 p.m.

On Tue, Apr 8, 2008 at 11:12 AM, Thomas Bächler wrote:

...

for those who are "lost" in the chaos of change (not everyone spent the last few days on this topic as you did).

True, I'll give you that - but I just always assume people will read the script if something is unclear. Teach a man to fish, etc. Anyone is welcome to ask me anything, as I thought I covered all the bases, but probably explained things poorly. Jabber and/or private email also work too.

Pierre Schmitz

12:17 p.m.

Am Dienstag, 8. April 2008 07:44:44 schrieb Aaron Griffin:

...

Let me know if I got all this right, and I covered everything enough for you all.

I think the commit-list does not work anymore, right? -- archlinux.de

Aaron Griffin

7:47 p.m.

On Tue, Apr 8, 2008 at 3:17 AM, Pierre Schmitz wrote:

...

I think the commit-list does not work anymore, right?

Yeah, I was meaning to re-add that. The same guy who makes cvslog also makes svnlog, which should maintain the same format. On Tue, Apr 8, 2008 at 3:48 AM, Simo Leone wrote:

...

Hey guys, do *NOT* try these out quite yet. Removing packages from a db results in a segfault that leaves it on the web db, which will quickly desync it and make a mess. http://bugs.archlinux.org/task/10114

Bah, how often do we remove packages anyway. It's still fine for upgrades - the "do *NOT*" warning is jumping the gun. I will fix this when I get a chance. On Tue, Apr 8, 2008 at 10:06 AM, Jeff Mickey wrote:

...

As brought up on irc by bash, communitypkg no longer works. /usr/bin/communitypkg is merely a symlink to /usr/bin/extrapkg, and extrapkg has the svn commit lines instead of the CVS lines needed for community. I'm not sure if this is "bug worthy", but I opened a bug in community packages so TU's have a reference:

http://bugs.archlinux.org/task/10118

To all TU's, either downgrade or don't upgrade devtools until this can be fixed. I mean, you could always use "cvs commit".

Good catch. I didn't even pick up on that one. Now the kicker - how quickly can I/we get the community daemon converted vs putting out a new devtools package? Which way should we go?

Thomas Bächler

8:08 p.m.

Aaron Griffin schrieb:

...

On Tue, Apr 8, 2008 at 3:48 AM, Simo Leone wrote:

...
Hey guys, do *NOT* try these out quite yet. Removing packages from a db results in a segfault that leaves it on the web db, which will quickly desync it and make a mess. http://bugs.archlinux.org/task/10114

Bah, how often do we remove packages anyway. It's still fine for upgrades - the "do *NOT*" warning is jumping the gun. I will fix this when I get a chance.

Everytime we remove something from testing to move it to core/extra. Due to the signoff rule, that happens a lot.

...

...
/usr/bin/communitypkg is merely a symlink to /usr/bin/extrapkg, and extrapkg has the svn commit lines instead of the CVS lines needed for community. I'm not sure if this is "bug worthy", but I opened a bug in community packages so TU's have a reference:

http://bugs.archlinux.org/task/10118

To all TU's, either downgrade or don't upgrade devtools until this can be fixed. I mean, you could always use "cvs commit".

Good catch. I didn't even pick up on that one. Now the kicker - how quickly can I/we get the community daemon converted vs putting out a new devtools package? Which way should we go?

Instead of a symlink, use the old (CVS-)extrapkg as communitypkg. That will effectively fix communitypkg, so you can take your time to convert community. As I understand you, no work has been done on that yet.

Aaron Griffin

8:13 p.m.

On Tue, Apr 8, 2008 at 11:08 AM, Thomas Bächler wrote:

...

Aaron Griffin schrieb:

...
On Tue, Apr 8, 2008 at 3:48 AM, Simo Leone wrote:

...
Hey guys, do *NOT* try these out quite yet. Removing packages from a db results in a segfault that leaves it on the web db, which will quickly desync it and make a mess. http://bugs.archlinux.org/task/10114

Bah, how often do we remove packages anyway. It's still fine for upgrades - the "do *NOT*" warning is jumping the gun. I will fix this when I get a chance.

Everytime we remove something from testing to move it to core/extra. Due to the signoff rule, that happens a lot.

I just meant that the previous email sounded like a "Everyone panic!" email... but it's really not a huge deal. I may have just fixed it anyway.

...

...
...
/usr/bin/communitypkg is merely a symlink to /usr/bin/extrapkg, and extrapkg has the svn commit lines instead of the CVS lines needed for community. I'm not sure if this is "bug worthy", but I opened a bug in community packages so TU's have a reference:

http://bugs.archlinux.org/task/10118

To all TU's, either downgrade or don't upgrade devtools until this can be fixed. I mean, you could always use "cvs commit".

Good catch. I didn't even pick up on that one. Now the kicker - how quickly can I/we get the community daemon converted vs putting out a new devtools package? Which way should we go?

Instead of a symlink, use the old (CVS-)extrapkg as communitypkg. That will effectively fix communitypkg, so you can take your time to convert community. As I understand you, no work has been done on that yet.

Hmm, that's probably be the path of least resistance - Jason, opinions?

Jason Chu

8:21 p.m.

...

...
...
...
/usr/bin/communitypkg is merely a symlink to /usr/bin/extrapkg, and extrapkg has the svn commit lines instead of the CVS lines needed for community. I'm not sure if this is "bug worthy", but I opened a bug in community packages so TU's have a reference:

http://bugs.archlinux.org/task/10118

To all TU's, either downgrade or don't upgrade devtools until this can be fixed. I mean, you could always use "cvs commit".

Good catch. I didn't even pick up on that one. Now the kicker - how quickly can I/we get the community daemon converted vs putting out a new devtools package? Which way should we go?

Instead of a symlink, use the old (CVS-)extrapkg as communitypkg. That will effectively fix communitypkg, so you can take your time to convert community. As I understand you, no work has been done on that yet.

Hmm, that's probably be the path of least resistance - Jason, opinions?

Sounds like a nice quick fix for now. I'll release 0.6.2 soon! Jason

Jason Chu

8:36 p.m.

On Tue, Apr 08, 2008 at 09:21:48AM -0700, Jason Chu wrote:

...

...
...
...
...
/usr/bin/communitypkg is merely a symlink to /usr/bin/extrapkg, and extrapkg has the svn commit lines instead of the CVS lines needed for community. I'm not sure if this is "bug worthy", but I opened a bug in community packages so TU's have a reference:

http://bugs.archlinux.org/task/10118

To all TU's, either downgrade or don't upgrade devtools until this can be fixed. I mean, you could always use "cvs commit".

Good catch. I didn't even pick up on that one. Now the kicker - how quickly can I/we get the community daemon converted vs putting out a new devtools package? Which way should we go?

Instead of a symlink, use the old (CVS-)extrapkg as communitypkg. That will effectively fix communitypkg, so you can take your time to convert community. As I understand you, no work has been done on that yet.

Hmm, that's probably be the path of least resistance - Jason, opinions?

Sounds like a nice quick fix for now. I'll release 0.6.2 soon!

Jason

Oh crap. The symlink is actually created in aurtools. That'll teach us for actually trying to separate ideas. I'll see if I can get Paul to just take a copy of the old communitypkg script and put it in aurtools for right now. I like not screwing with the extrapkg script because it's correct for when everything is converted over. Jason

Paul Mattal

8:59 p.m.

Jason Chu wrote:

...

On Tue, Apr 08, 2008 at 09:21:48AM -0700, Jason Chu wrote:

...
...
...
...
...
/usr/bin/communitypkg is merely a symlink to /usr/bin/extrapkg, and extrapkg has the svn commit lines instead of the CVS lines needed for community. I'm not sure if this is "bug worthy", but I opened a bug in community packages so TU's have a reference:

http://bugs.archlinux.org/task/10118

To all TU's, either downgrade or don't upgrade devtools until this can be fixed. I mean, you could always use "cvs commit".

Good catch. I didn't even pick up on that one. Now the kicker - how quickly can I/we get the community daemon converted vs putting out a new devtools package? Which way should we go?

Instead of a symlink, use the old (CVS-)extrapkg as communitypkg. That will effectively fix communitypkg, so you can take your time to convert community. As I understand you, no work has been done on that yet. Hmm, that's probably be the path of least resistance - Jason, opinions? Sounds like a nice quick fix for now. I'll release 0.6.2 soon!

Jason

Oh crap. The symlink is actually created in aurtools. That'll teach us for actually trying to separate ideas. I'll see if I can get Paul to just take a copy of the old communitypkg script and put it in aurtools for right now.

I think you have. I have just released an aurtools 1.3.0-2 that incorporates a frozen copy of the old extrapkg for now. Can someone build for x86_64? - P

Simo Leone

12:48 p.m.

On Mon, Apr 07, 2008 at 11:57:00PM -0500, Aaron Griffin wrote:

...

Report anything and everything.

Hey guys, do *NOT* try these out quite yet. Removing packages from a db results in a segfault that leaves it on the web db, which will quickly desync it and make a mess. http://bugs.archlinux.org/task/10114 -S

Jan de Groot

5 Apr 5 Apr

11:30 p.m.

On Sat, 2008-04-05 at 12:25 -0500, Aaron Griffin wrote:

...

On Thu, Apr 3, 2008 at 9:54 AM, Aaron Griffin wrote:

...
I will be back on Saturday, so I plan on doing this then, starting about 10am CST on Saturday.

Due to some flight issues, I will not be home for another 5 hours or so. I will begin the conversion then.

Jason, are you willing to commit the devtools changes to speed this up?

The conversion itself should not take too long, as Jason made a neat little script to do it.

Jason or Eliott, if you have the time and want to speed this up, could you possibly set the cvs repos to read-only. There is a conversion script in ~aaron/svnarch that you can run too, if you're feeling sassy.

I'd like to mimic the cvs naming, so /home/cvs-extra == /home/svn-extra if someone does end up doing this.

If not, I will get to it soon. I have a bit more time before my flight, but not enough to start this process right now. Feel free to contact me on jabber for the next 15mins or so

At this moment I'm busy moving gnome from testing to extra. part of this move is a massive GStreamer cleanup which saves you quite some shit to convert ;) I'll report when I'm done, I don't expect this will take ages.

Jan de Groot

6 Apr 6 Apr

1:08 a.m.

On Sat, 2008-04-05 at 21:30 +0200, Jan de Groot wrote:

...

On Sat, 2008-04-05 at 12:25 -0500, Aaron Griffin wrote:

...
On Thu, Apr 3, 2008 at 9:54 AM, Aaron Griffin wrote:

...
I will be back on Saturday, so I plan on doing this then, starting about 10am CST on Saturday.

Due to some flight issues, I will not be home for another 5 hours or so. I will begin the conversion then.

Jason, are you willing to commit the devtools changes to speed this up?

The conversion itself should not take too long, as Jason made a neat little script to do it.

Jason or Eliott, if you have the time and want to speed this up, could you possibly set the cvs repos to read-only. There is a conversion script in ~aaron/svnarch that you can run too, if you're feeling sassy.

I'd like to mimic the cvs naming, so /home/cvs-extra == /home/svn-extra if someone does end up doing this.

If not, I will get to it soon. I have a bit more time before my flight, but not enough to start this process right now. Feel free to contact me on jabber for the next 15mins or so

At this moment I'm busy moving gnome from testing to extra. part of this move is a massive GStreamer cleanup which saves you quite some shit to convert ;)

I'll report when I'm done, I don't expect this will take ages.

Ok, go ahead. CVS changes are done for now, GNOME and friends have been moved from testing to extra for both architectures. There's a lot of things still in testing, but most packages have been moved now.

Aaron Griffin

3:49 a.m.

On Sat, Apr 5, 2008 at 4:08 PM, Jan de Groot wrote:

...

On Sat, 2008-04-05 at 21:30 +0200, Jan de Groot wrote:

...
On Sat, 2008-04-05 at 12:25 -0500, Aaron Griffin wrote:

...
On Thu, Apr 3, 2008 at 9:54 AM, Aaron Griffin wrote:

...
I will be back on Saturday, so I plan on doing this then, starting about 10am CST on Saturday.

Due to some flight issues, I will not be home for another 5 hours or so. I will begin the conversion then.

Jason, are you willing to commit the devtools changes to speed this up?

The conversion itself should not take too long, as Jason made a neat little script to do it.

Jason or Eliott, if you have the time and want to speed this up, could you possibly set the cvs repos to read-only. There is a conversion script in ~aaron/svnarch that you can run too, if you're feeling sassy.

I'd like to mimic the cvs naming, so /home/cvs-extra == /home/svn-extra if someone does end up doing this.

If not, I will get to it soon. I have a bit more time before my flight, but not enough to start this process right now. Feel free to contact me on jabber for the next 15mins or so

At this moment I'm busy moving gnome from testing to extra. part of this move is a massive GStreamer cleanup which saves you quite some shit to convert ;)

I'll report when I'm done, I don't expect this will take ages.

Ok, go ahead. CVS changes are done for now, GNOME and friends have been moved from testing to extra for both architectures. There's a lot of things still in testing, but most packages have been moved now.

Yeah, I expect everything to be fully functional by the end of Sunday (Monday morning for you guys) Thanks Jan, I'm going to begin all this shenanigans now.

Aaron Griffin

5:19 a.m.

On Sat, Apr 5, 2008 at 6:49 PM, Aaron Griffin wrote:

...

On Sat, Apr 5, 2008 at 4:08 PM, Jan de Groot wrote:

...
On Sat, 2008-04-05 at 21:30 +0200, Jan de Groot wrote:

...
On Sat, 2008-04-05 at 12:25 -0500, Aaron Griffin wrote:

...
On Thu, Apr 3, 2008 at 9:54 AM, Aaron Griffin wrote:

...
I will be back on Saturday, so I plan on doing this then, starting about 10am CST on Saturday.

Due to some flight issues, I will not be home for another 5 hours or so. I will begin the conversion then.

Jason, are you willing to commit the devtools changes to speed this up?

The conversion itself should not take too long, as Jason made a neat little script to do it.

Jason or Eliott, if you have the time and want to speed this up, could you possibly set the cvs repos to read-only. There is a conversion script in ~aaron/svnarch that you can run too, if you're feeling sassy.

I'd like to mimic the cvs naming, so /home/cvs-extra == /home/svn-extra if someone does end up doing this.

If not, I will get to it soon. I have a bit more time before my flight, but not enough to start this process right now. Feel free to contact me on jabber for the next 15mins or so

At this moment I'm busy moving gnome from testing to extra. part of this move is a massive GStreamer cleanup which saves you quite some shit to convert ;)

I'll report when I'm done, I don't expect this will take ages.

Ok, go ahead. CVS changes are done for now, GNOME and friends have been moved from testing to extra for both architectures. There's a lot of things still in testing, but most packages have been moved now.

Yeah, I expect everything to be fully functional by the end of Sunday (Monday morning for you guys)

Thanks Jan, I'm going to begin all this shenanigans now.

Shenanigans have begun. I am leaving community alone for now (that's tomorrow). It should all be committed to the svn repo, and Jason got the devtools changes in. I have personal things to attend to (it's 8pm right now), but I will be up bright-and-early to complete all this. Like I said - 24 hours of free time. It will probably be much less, but I am probably at the tail end of changes for tonight. Enjoy your "vacation" guys, heh.

5852

Age (days ago)

5870

Last active (days ago)

List overview

Download

93 comments

17 participants

participants (17)

Aaron Griffin
Alexander Baldeck
Dan McGee
Daniel Isenmann
eliott
Eric Belanger
Jan de Groot
Jason Chu
Jeff Mickey
Jürgen Hötzel
Paul Mattal
Pierre Schmitz
Roman Kyrylych
Simo Leone
Thayer Williams
Thomas Bächler
Travis Willard