On Fri, 28 Sep 2007, Aaron Griffin wrote:

On 9/28/07, Andreas Radke wrote:

...

Whenever I had tried out the devtools I had these issues:

- I always set a certain pkgdest in makepkg.conf. So (old and) new packages are stored centralized. This breaks checkpkg and {foo-repo}pkg as they expect old and new pkg in the current directory. Correct me if I missed any option to solve that.

I *think* Thomas may have fixed this recently, but I will check. It's definitely very easy to fix if not.

Now that I think about it, there another problem with checkpkg. It doesn't work when you use a server that requires a username/password, such as gerolde, for your repo in pacman.conf. The username/password gets stripped from the url by the script and, not surprisingly, you are denied access from the server. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.

On Fri, 28 Sep 2007, Aaron Griffin wrote:

On 9/28/07, Eric Belanger wrote:

...

Now that I think about it, there another problem with checkpkg. It doesn't work when you use a server that requires a username/password, such as gerolde, for your repo in pacman.conf. The username/password gets stripped from the url by the script and, not surprisingly, you are denied access from the server.

Do you mean when it downloads the packages? That should be fixable, but not as quick as the other two.

Yes, it fails to download the current package in the repo in order to make the comparision with the new one. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.

On Mon, Oct 01, 2007 at 11:40:11PM -0500, Aaron Griffin wrote:

Ok, Dan and I cracked this out, after struggling with the git svn stuff for a bit.

http://projects.archlinux.org/git/?p=devtools.git;a=summary

Hey thanks guys. I too struggled with git-svn, you guys just happened to triumph. I'll remove the devtools svn in favour of the git project (once we release a new package and update the references). Jason

...

I'll remove the devtools svn in favour of the git project (once we release a new package and update the references).

Yeah. I didn't know the devtools PKGBUILD used an svn pull - we should probably push a real tarball up to the ftp dirs like we do with pacman.

That sounds like an excellent idea. At this point I don't know what's needed with devtools to make a new release. Can everyone who cares make a comment on anything they want in devtools? I'll start evaluating when I can make a new release. Jason

On 10/2/07, Thomas Bächler wrote:

Jason Chu schrieb:

...

At this point I don't know what's needed with devtools to make a new release. Can everyone who cares make a comment on anything they want in devtools? I'll start evaluating when I can make a new release.

You should include that one, as well as the patches from Archlinux CVS. http://archlinux.org/pipermail/arch-dev-public/2007-September/001831.html

http://projects.archlinux.org/git/?p=devtools.git;a=summary I think we got most of that in there last night. Let us know what is missing. -Dan

On 10/2/07, Eric Belanger wrote:

b) I haven't submitted the bug report yet. Maybe it would be safer and easier to have a configure option or a config file for checkpkg to specify the server to be used by it.

Hmmm this is a good point. I will think about ways around this specific to checkpkg and not pacman, necessarily

On Wed, 3 Oct 2007 12:42:33 -0500 "Aaron Griffin" wrote:

Ping? We made these changes - could you respond and let us know if they work for you or not?

Tried the new devtools from git, but following error appears: ---snip---- [ise@fuckup-ng mp3blaster]$ extrapkg daniel@archlinux.org's password: mp3blaster-3.2.3-3-i686.pkg.tar.gz 100% 218KB 54.5KB/s 00:04 daniel@archlinux.org's password: md5sum: staging/extra/add//home/ise/packages/mp3blaster-3.2.3-3-i686.pkg.tar.gz: No such file or directory File got corrupted during upload, cancelled. ---snip---- The error is in the md5sum check on line 56: if [ "$(md5sum $pkgfile | cut -d' ' -f1)" != "$(ssh archlinux.org md5sum staging/${repo}/add/$pkgfile | cut -d' ' -f1)" ]; then The variable $pkgfile is wrong, it was set right in the top of the script: pkgfile=${pkgname}-${pkgver}-${pkgrel}-${CARCH}.pkg.tar.gz But it changed to: "pkgfile=$PKGDEST/$pkgfile" just some lines lower. Daniel

On 10/4/07, Daniel Isenmann wrote:

Hi,

Thomas told me that he has fixed the issue, which I have reported. I had test the new devtools from git and they work without any problems. I have checked only the extrapkg script.

Hooray. Andy, can you see if the checkpkg changes work?

one checkpkg issue - $PKGDEST isn't sourced well:

usr/share/icu/3.8/mkinstalldirs usr/share/licenses/ usr/share/licenses/icu/ usr/share/licenses/icu/license.html tar: ..//home/daten/arch64/packages/testing/icu-3.8-1-x86_64.pkg.tar.gz: Kann open nicht ausführen: Datei oder Verzeichnis nicht gefunden tar: Nicht behebbarer Fehler: Programmabbruch. tar: Child returned status 2 tar: Fehler beim Beenden, verursacht durch vorhergehende Fehler. usr/lib/libicudata.so.38: SONAME libicudata.so.38 usr/lib/libicudata.so.38.0: SONAME libicudata.so.38 usr/lib/libicui18n.so.38: SONAME libicui18n.so.38

new pkg icu-3.8-1-x86_64.pkg.tar.gz does exist: [andyrtr@workstation64 icu]$ ls -l /home/daten/arch64/packages/testing/icu-3.8-1-x86_64.pkg.tar.gz -rw-r--r-- 1 andyrtr users 6844521 4. Okt 19:41 /home/daten/arch64/packages/testing/icu-3.8-1-x86_64.pkg.tar.gz [andyrtr@workstation64 icu]$ tail /etc/makepkg.conf # #-- Destination: specify a fixed directory where all packages will be placed PKGDEST=/home/daten/arch64/packages/testing The condition with oldstylepkgfile overwrites the values: echo $pkgfile echo $PKGDEST /home/daten/arch64/packages/testing/icu-3.8-1-x86_64.pkg.tar.gz /home/daten/arch64/packages/testing the old pkg is oldstyle in this case. Andy

it comes from if diff filelist-old filelist | grep '\.so\.' > /dev/null 2>&1; then mkdir -p pkg cd pkg tar xzf ../$pkgfile > /dev/null <------- ??? for i in `diff ../filelist-old ../filelist | grep \> | grep \.so\. | awk '{print $2}'`; do echo -n "${i}: " objdump -p $i | grep SONAME done else echo "No filename differences" fi at the end of the script. isn't that one obsolete as it does simply nothing? Andy

Am Thu, 4 Oct 2007 13:26:23 -0500 schrieb "Aaron Griffin" :

On 10/4/07, Andreas Radke wrote:

...

tar: ..//home/daten/arch64/packages/testing/icu-3.8-1-x86_64.pkg.tar.gz: Kann open nicht ausführen: Datei oder Verzeichnis nicht gefunden tar: Nicht behebbarer Fehler: Programmabbruch.

Could someone translate, for clarity?

tar: ..//home/daten/arch64/packages/testing/icu-3.8-1-x86_64.pkg.tar.gz: Cannot open: No such file or directory tar: Error is not recoverable: exiting now tar: Child returned status 2 tar: Error exit delayed from previous errors Andy

On 10/4/07, Andreas Radke wrote:

extrapkg issue:

[andyrtr@workstation64 icu]$ extrapkg -l 60 andyrtr@gerolde.archlinux.org's password: icu-3.8-1-x86_64.pkg.tar.gz 100% 6684KB 7.4KB/s 15:00 andyrtr@gerolde.archlinux.org's password: File integrity okay. ===> Uploaded /home/daten/arch64/packages/testing/icu-3.8-1-x86_64.pkg.tar.gz cvs commit: Examining . andyrtr@cvs.archlinux.org's password: cvs commit: Up-to-date check failed for `PKGBUILD' cvs [commit aborted]: correct above errors first! Cancelled [andyrtr@workstation64 icu]$

The speedlimit worked well. but it seems to break the -m comment for cvs commit.

That error looks more like the commit failed. The -m argument is for the commit message, this error is different. It means there's a conflict in CVS. cvs commit: Up-to-date check failed for `PKGBUILD' cvs [commit aborted]: correct above errors first!

Beside that i have a big problem with the strict order to first upload the package and then commit/tag it. OpenOffice.org needs me 4 hours to upload. When I will not sit in front of the pc when it comes to commit/tag the server will reject me due to a timeout. Any idea if/how this can be solved?

Well, we could do it in reverse, I don't see a big problem with that... anyone else?

On Thu, Oct 04, 2007 at 02:49:16PM -0500, Aaron Griffin wrote:

On 10/4/07, Andreas Radke wrote:

...

extrapkg issue:

[andyrtr@workstation64 icu]$ extrapkg -l 60 andyrtr@gerolde.archlinux.org's password: icu-3.8-1-x86_64.pkg.tar.gz 100% 6684KB 7.4KB/s 15:00 andyrtr@gerolde.archlinux.org's password: File integrity okay. ===> Uploaded /home/daten/arch64/packages/testing/icu-3.8-1-x86_64.pkg.tar.gz cvs commit: Examining . andyrtr@cvs.archlinux.org's password: cvs commit: Up-to-date check failed for `PKGBUILD' cvs [commit aborted]: correct above errors first! Cancelled [andyrtr@workstation64 icu]$

The speedlimit worked well. but it seems to break the -m comment for cvs commit.

That error looks more like the commit failed. The -m argument is for the commit message, this error is different. It means there's a conflict in CVS.

cvs commit: Up-to-date check failed for `PKGBUILD' cvs [commit aborted]: correct above errors first!

...

Beside that i have a big problem with the strict order to first upload the package and then commit/tag it. OpenOffice.org needs me 4 hours to upload. When I will not sit in front of the pc when it comes to commit/tag the server will reject me due to a timeout. Any idea if/how this can be solved?

Well, we could do it in reverse, I don't see a big problem with that... anyone else?

I didn't want to commit (mostly tag) until after the package was available on the server. Once a package has been tagged, we'll start seeing errors because it's not in the staging dir when you run db-extra. We could still commit first, but you'd probably run into the same timeout issue if we just tag though. Jason

On 10/4/07, Jason Chu wrote:

On Thu, Oct 04, 2007 at 02:49:16PM -0500, Aaron Griffin wrote:

...

On 10/4/07, Andreas Radke wrote:

...

extrapkg issue:

[andyrtr@workstation64 icu]$ extrapkg -l 60 andyrtr@gerolde.archlinux.org's password: icu-3.8-1-x86_64.pkg.tar.gz 100% 6684KB 7.4KB/s 15:00 andyrtr@gerolde.archlinux.org's password: File integrity okay. ===> Uploaded /home/daten/arch64/packages/testing/icu-3.8-1-x86_64.pkg.tar.gz cvs commit: Examining . andyrtr@cvs.archlinux.org's password: cvs commit: Up-to-date check failed for `PKGBUILD' cvs [commit aborted]: correct above errors first! Cancelled [andyrtr@workstation64 icu]$

The speedlimit worked well. but it seems to break the -m comment for cvs commit.

That error looks more like the commit failed. The -m argument is for the commit message, this error is different. It means there's a conflict in CVS.

cvs commit: Up-to-date check failed for `PKGBUILD' cvs [commit aborted]: correct above errors first!

...

Beside that i have a big problem with the strict order to first upload the package and then commit/tag it. OpenOffice.org needs me 4 hours to upload. When I will not sit in front of the pc when it comes to commit/tag the server will reject me due to a timeout. Any idea if/how this can be solved?

Well, we could do it in reverse, I don't see a big problem with that... anyone else?

I didn't want to commit (mostly tag) until after the package was available on the server. Once a package has been tagged, we'll start seeing errors because it's not in the staging dir when you run db-extra.

We could still commit first, but you'd probably run into the same timeout issue if we just tag though.

Yeah, I was afraid there was something I was forgetting. In all honesty, I think Eric's solution is the best here. We're uploading/committing in a certain order because it's the proper way, but the issue here is specific to your machine, so we should solve this on your machine. Would someone mind writing up a quick HOWTO in the dev wiki for using ssh keys on gerolde - for those that haven't done it yet?

On Thu, 4 Oct 2007, Aaron Griffin wrote:

On 10/4/07, Thomas Bächler wrote:

...

Andreas Radke schrieb:

...

Beside that i have a big problem with the strict order to first upload the package and then commit/tag it. OpenOffice.org needs me 4 hours to upload. When I will not sit in front of the pc when it comes to commit/tag the server will reject me due to a timeout. Any idea if/how this can be solved?

As already mentioned, you could use ssh keys. As my /home is encrypted, I use my key without a passphrase, but you could use a passphrase and ssh-agent (if you lock your screen during your absence, nobody will be able to login to gerolde). Using keys is much more secure than password authentication anyway.

Additionally, I use ssh master mode:

[thomas@artin ~]$ cat .ssh/config ControlPath /home/thomas/.ssh/master-%h-%p-%r

Host gerolde HostName archlinux.org

Host cvs.archlinux.org HostName archlinux.org

I now launch ssh -M gerolde. That creates a master connection, that all other ssh connections to the same host are tunneled through (thus the alias from cvs.archlinux.org to archlinux.org). The authentication problem remains the same, but as only one connection is established, the cvs commit and tag operations are done much quicker. I recommend to for anyone who is working much on arch cvs/git/upload via ssh.

Further reading: http://phraktured.net/ssh-connection-control.html

There's an article in the wiki: http://wiki.archlinux.org/index.php/Using_SSH_Keys That's the information source I use to create my setup. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.