Re: mini-dinstall, repository signing and apt-get authentication

[Neil Williams]

Darren Salt wrote:
> What I use for my repository is attached. (Licence is GPL >= v2.)

Excellent! Thank you!

I've tweaked it a little so far to accept the architecture name as the
first command option and I'm running it manually after changing into
each directory. It should be simple to automate from there, including
tacking on the command to sign the Release file.

With mini-dinstall now set to *not* create Release files, I just need to
create a suitable wrapper to run as a post-install script via
mini-dinstall itself.

$ cd amd64/
$ rm Release
$ bash ~/release.sh amd64
$ ~/.scripts/.sign Release
$ cd ../powerpc/
etc.

At the top level, (when $1 is not set), it simply outputs a replacement
string that includes each arch.
if [ ! $1 ]
then
ARCH="all amd64 powerpc i386"
codename="packages/$i"
else
ARCH=$1
codename="packages/$i/$ARCH"
fi

It works!

-- 

Neil Williams
=
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/




signature.asc
Description: OpenPGP digital signature

[MailServer Notification]Attachment Blocking Notification

[scanmail]

The mkrelease.sh has been blocked,
and Quarantine entire message has been taken on 7/29/2006 2:42:57 AM.
Message details:
Server:AZINDBAEX01
Sen7/29/20062:42:57 AMQuarantine entire messagemkrelease.shder: [EMAIL 
PROTECTED];
Recipient:debian-mentors@lists.debian.org;
Subject:Re: mini-dinstall, repository signing and apt-get authentication
Attachment name:mkrelease.sh


The information contained in, or attached to, this e-mail, contains 
confidential information and is intended solely for the use of the individual 
or entity to whom they are addressed and is subject to legal privilege. If you 
have received this e-mail in error you should notify the sender immediately by 
reply e-mail, delete the message from your system and notify your system 
manager. Please do not copy it for any purpose, or disclose its contents to any 
other person. The views or opinions presented in this e-mail are solely those 
of the author and do not necessarily represent those of the company. The 
recipient should check this e-mail and any attachments for the presence of 
viruses. The company accepts no liability for any damage caused, directly or 
indirectly, by any virus transmitted in this email.

www.aztecsoft.com


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: mini-dinstall, repository signing and apt-get authentication

[Darren Salt]

I demand that Neil Williams may or may not have written...

[snip]
> I'm now trying a brute force method:

> $ cp /home/neil/Release.amd64 ./Release
> $ md5sum Packages >> Release
> $ md5sum Packages.gz >> Release
> $ echo "SHA1:" >> ./Release
> $ sha1sum Packages >> ./Release
> $ sha1sum Packages.gz >> ./Release

> then signing the Release file to create Release.gpg

What I use for my repository is attached. (Licence is GPL >= v2.)

-- 
| Darren Salt| linux or ds at  | nr. Ashington, | Toon
| RISC OS, Linux | youmustbejoking,demon,co,uk | Northumberland | Army
|   Say NO to UK ID cards. http://www.no2id.net/

I will never lie to me.
#! /bin/sh

i=unstable
ARCH=amd64

exec >Release

cat addfile ($fd);
my @stat = stat ($file) or die $^E;
printf " %s %8s %s\n", $hash->hexdigest, $stat[7], $file;
undef $hash;
close $fd;
  }
}

my @args;
while (<>) { chomp; push @args, $_; }
exit 0 unless @args;
print "MD5Sum:\n";
write_sum ("MD5", @args);
print "SHA1:\n";
write_sum ("SHA1", @args);'


signature.asc
Description: PGP signature

Re: mini-dinstall, repository signing and apt-get authentication

[Neil Williams]

George Danchev wrote:
> On Tuesday 25 July 2006 21:20, Neil Williams wrote:
> --cut--
>> That's what I used to use but this method can't be used with
>> mini-dinstall. It looks like your repository is a single subdirectory
>> whereas mine uses multiple subdirectories for the multiple
>> architectures. Each one, apparently, needs a customised Release file.
> 
> let mini-dinstall generates these Release files on the server side

This is a problem. mini-dinstall does not create all the required
Release files. It only creates the top level Release file.

When I try to create a Release file with apt-ftparchive in the
architecture-specific subdirectory, apt-ftparchive recurses UP the tree
and interferes with the Release file generated by mini-dinstall in the
directory above. The Release file written by apt-ftparchive is not valid
anyway.
W: Conflicting distribution: http://www.linux.codehelp.co.uk
packages/unstable/amd64/ Release (expected packages/unstable/amd64 but
got "data-freedom")

I've had to delete the Release and Release.gpg files from each
subdirectory for now.

When I create a dummy Release file, apt-get update complains that no
MD5Sum entries are found so I need to copy the Release file from the
directory above. Doing that then confuses apt-get without some nasty sed
hacking to mangle the directory names for each MD5Sum to correctly
identify the subdirectory and limit the Architecture: line to just the
architecture in that subdirectory.

It appears that mini-dinstall simply does not support all the declared
options. generate-release does not appear to work for
archive_style=simple-subdir, at least it doesn't if more than one
architecture is specified.

Time for a bug report, I think. But in order to actually get the thing
working, I need more help.

Is there another way of generating a Release file?

What is the underlying method, avoiding all use of devscript tools?

I'm now trying a brute force method:

$ cp /home/neil/Release.amd64 ./Release
$ md5sum Packages >> Release
$ md5sum Packages.gz >> Release
$ echo "SHA1:" >> ./Release
$ sha1sum Packages >> ./Release
$ sha1sum Packages.gz >> ./Release

then signing the Release file to create Release.gpg

I get:
Failed to fetch
http://www.linux.codehelp.co.uk/packages/unstable/amd64/Release  Unable
to find expected entry  Packages in Meta-index file (malformed Release
file?)

The base Release file is:
Archive: unstable
Origin: "Neil Williams <[EMAIL PROTECTED]>"
Component: main
Label: "Data Freedom demo packages"
Architecture: amd64
Packages: amd64/Packages
MD5Sum:

What's missing / wrong?
(I've tried with and without the Packages: line. The rest is as per the
Debian Repository HOWTO.)

For this repository:
http://www.linux.codehelp.co.uk/packages/unstable/amd64/Release

What should the Release file in amd64/ contain?

-- 

Neil Williams
=
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/




signature.asc
Description: OpenPGP digital signature

Re: using cow-shell to build a package

[Martin Man]

Hi Bastian,

Bastian Venthur napsal(a):
> Hi all,
> 
> [snip/]
> 
> Is it possible to login to a clean environment with you package, make
> changes and test until its ready and leave the environment later with no
> changes made to the environment but the package-tree? Does cow-shell
> provide this functionality. If yes, how?

I have no answer to your question, but I did exactly what you describe
using pbuilder, you can even optimize the process and loop-mount some
directory to the pbuilder so that you don't loose your changes after you
tweak rules properly...

As I think about it, I did set it up in a way that post-build hook in
pbuilder (or was it pre-build hook?) invoked interactive bash for me,
and I could continue using modify debian/rules && dpkg-buildpckage right
from the extracted & patched sources in a pbuilder provided chroot.

> Cheers,

HTH,
Martin


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

using cow-shell to build a package

[Bastian Venthur]

Hi all,

I'm currently using cowbuilder to build a package. It is much faster
than pbuilder but sometimes not fast enough. I'm currently working on a
package which involves tweaking the debian/rules for the right settings.
After every change I have to invoke cowbuilder which takes a lot of time.

Is it possible to login to a clean environment with you package, make
changes and test until its ready and leave the environment later with no
changes made to the environment but the package-tree? Does cow-shell
provide this functionality. If yes, how?


Cheers,
-- 
Bastian Venthur
http://venthur.de


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]