On 2009-02-25 14:59:38 +0100, Michael Schroeder wrote:

On Mon, Feb 23, 2009 at 01:54:12AM +0100, Marcus Hüwe wrote:

...

I wrote a small patch to inject rpm/deb/whatever data to the buildinfo calculation. This means one can collect the rpm/deb provides and requires of local packages and send them to the obs which uses them to calculate the buildinfo for local builds.

Heh, this is a feature that was actually already discussed with Peter but never reached the implementation phase.

Yes Peter told me the same:)

How about using Build.pm's internal format?

Indeed that's a good idea.

...

• # FIXME: is there a to check for the cpio magic?

Of course there is, it must start with "070701". You can use this for autodetection, i.e. no need for the "cpio" switch.

The problem is that there's no easy way to check for the magic. We can't use the existing BSServer::read_data() method because it reads directly from the socket. So if we do something like: if (BSServer::read_data(6, 1) eq '070701') { BSServer::read_cpio(...) } the read_cpio() will complain because it doesn't find the magic anymore.

The following should work in theory: BSServer::read_file($fn); # store cpio archive _or_ plain text file in a file # (it reads all the POSTed data)

Now we can easily check if $fn starts with 070701. The only problem with this approach is that we would need to outsource parts from BSHTTP::cpio_receiver() into a more "generic" method (basically we only need to pass a ref to method which reads the data (either from a file or from a socket)).

Or is there an easy way which I didn't found?:)

Have you already patched osc so that it sends the extra data?

No I didn't start with the osc implementation yet (but Peter already checked in a module which can be used to create a cpio archive).

Marcus

On 2009-02-25 17:28:09 +0100, Michael Schroeder wrote:

On Wed, Feb 25, 2009 at 05:24:58PM +0100, Marcus Hüwe wrote:

...

Now we can easily check if $fn starts with 070701. The only problem with this approach is that we would need to outsource parts from BSHTTP::cpio_receiver() into a more "generic" method (basically we only need to pass a ref to method which reads the data (either from a file or from a socket)).

Or is there an easy way which I didn't found?:)

Hah, see my commit a couple of hours ago. You can now do:

Ah I would have needed it before sunday in order to save some time:)

open(F, '<', $cpiofile) || die("$cpiofile: $!\n");
my $uploaded = BSHTTP::cpio_receiver(BSHTTP::fd2hdr(\*F), {'directory' => $dir});
close F;

Awesome! Thanks! I'll incorporate all your suggestions and post a new patch afterwards.

Marcus

On Thu, Feb 26, 2009 at 01:16:49PM +0100, Marcus Hüwe wrote:

the format which is used by Build::readdeps() looks like this: P:<id>: <list of provides separated by a whitespace> R:<id>: <list of requires separated by a whitespace> And <id> looks like <pkgname><some other info> - at least that's the impression I got after reading the code + looking at e.g. createyastdeps. So an example entry would look like this:

P:foo-bar-gui-qt: foo-bar-gui-qt = 1.0 R:foo-bar-gui-qt: libfoo P:foo-bar-gui-gtk: foo-bar-gui-gtk = 1.0 R:foo-bar-gui-gtk: libbar

These are valid package names but aren't parsed correctly by Build::readdeps() which is due to ... if ($s =~ s/^P:(.*):$/$1/) { my $pkgid = $s; $s =~ s/-[^-]+-[^-]+-[^-]+$//; $provides{$s} = @ss; ... # the same for provides

Yep, Build::readdeps() is broken. It still is only able to parse the old autobuild format while the Build.pm code nowadays writes some slight different format. Luckily this part of readdeps() isn't used at all, thus we're free to fix it.

The problem is that I didn't get the idea of this substitute (apart from causing problems). Additionally what's the idea of the $pkgidp hashref which can be passed to Build::readdeps()?

It can be used to record the package->pkgid relation. Used in legacy autobuild code.

Cheers, Michael.

Marcus Hüwe wrote:

On 2009-02-26 14:24:02 +0100, Michael Schroeder wrote:

...

Yep, Build::readdeps() is broken. It still is only able to parse the old autobuild format while the Build.pm code nowadays writes some slight different format. Luckily this part of readdeps() isn't used at all, thus we're free to fix it.

Ok this sounds good. Yet another question: is the current format used somewhere else?

Files with that format are created by create*deps scripts and parsed by expanddeps.

Because otherwise it would be cool if it's possible to slightly change the format. At the moment it has the following structure: ... I:<pkgid>: <name>-<version>-<release> <buildtime> ... My proposal is to separate <name>, <version> and <release> with a whitespace instead of the dash because it would be easier to parse the name version and release of a package (I need this info in order to send back a "clean" buildinfo).

That line is (optionally) used by init_buildsystem to speed up installation. See RPMIDFMT in there. It is possible to change the format but existing srcfiles.cache in build roots have to be rebuilt then.

cu Ludwig

On 2009-02-27 11:00:01 +0100, Michael Schroeder wrote:

On Thu, Feb 26, 2009 at 08:43:35PM +0100, Marcus Hüwe wrote:

...

My proposal is to separate <name>, <version> and <release> with a whitespace instead of the dash because it would be easier to parse the name version and release of a package (I need this info in order to send back a "clean" buildinfo).

We could do that, but it really isn't that hard to split the version/release with the current version...

Here's a new version of the patch: build/Build.pm: * rewrote some parts of readdeps(), it parses the current format which is used by build and also supports debian requires/provides (foo | bar (>> 3.1)...) * removed $strip_versions module variable * the former $pkgidp ref of readdeps() is now used to store package information (version, release, arch) (the self provides of a package is used to determine this information) backend/bs_repserver: * some minor changes with regard to the last patch * local packages are preferred

Feedback, objections etc. are welcome:)

Marcus