Hi,

here’s a small summary of the 7th (coding) week. Last week
I was really busy with university stuff (it was the second
last week in the lecture period so I had to recap quite
some stuff) and didn’t manage to work much on the GSoC project.
I’m going work off the TODO this weekend.

Marcus

Hi

here’s a small summary of the 6th (coding) week. Last week I
continued working on the build module and developed a concept
for the package fetcher (and discussed some parts
with darix:) ).
The main idea is to modularize the fetcher code, verify code etc.
Thus we have a fetcher class which takes care of retrieving the
packages. The fetcher class utilizes a “cache manager” which takes
care of storing the fetched packages on the filesystem. The goal is
that at some point in time one can exchange the “simple” cache manager
with a more “clever” cache manager (which for instance cleans up the
cache from time to time or only allows exactly one version of a
package in the cache etc.). In order to achieve this no code in the
fetcher has to be touched – instead it’s sufficient to pass a different
cache manager object to the fetcher.
Additionally the fetcher provides some hooks like pre, pre_fetch,
post_fetch and post. For instance a post_fetch hook can be used to
verify the just fetched package etc.

TODO:
– write testcases and implement the concept from above

If you have questions, suggestions etc. feel free to contact me:)

Marcus

Hi,

here’s a small summary of the 5th (coding) week. Last week I spent
most of my time with working on the cpio module. Finally I ended
up with a complete rewrite of osc’s “old” cpio module. The
cpio implementation details are taken from the cpio 2.11 package.
Currently only the “new ascii” format is supported and we can
only handle regular files (this is sufficient for our needs). Here’s
a small example how to use it:

# cpio_open is just a convenience method for CpioArchive(filename=fname)
with cpio_open(fname) as archive:
    for archive_file in archive:
        # print filename
        print archive_file.hdr.name
        # print contents
        print archive_file.read()

It’s also possible to pass a file-like object to a CpioArchive
instance (in this case we do not need to use the with statement).
Also it can be “easily” enhanced to support different cpio formats
(one just have to write the specific ArchiveReader and ArchiveWriter
classes:) ). The code is available at [1] and the testcases at [2].

Todo for this week:
* finish the build module
* start with working on the package fetching code

Marcus

[1] https://github.com/openSUSE/osc2/blob/master/osc/util/cpio.py
[2] https://github.com/openSUSE/osc2/blob/master/test/util/test_cpio.py

Hi,

here’s a small summary of the 3rd and 4th (coding) week . First of all I
wasn’t able to do lots of work in week 3 and 4 so I’m still working on
the new build module for the osc2 library.
The initial plan was to copy/reuse some of the existing modules from the
(old) “osc” like the cpio [1] and packagequery modules. But I decided to
refactor/rewrite cpio module for the following reasons:

• “save” disc space:
  In our scenario we retrieve a cpio archive from the api (which contains
  binary packages for example). The old cpio module expects a filename
  in order to “unpack” the archive – that is the file has to be stored on
  disc first. Consequently approximately 2 * of free disc
  space is needed.
  The new idea is that we pass a file-like object (in our case an object
  which inherits from “AbstractHTTPResponse”) to the cpio module and
  unpack the archive “on the fly” (without storing the http response
  on disc first).
• have testcases:
  The old cpio module has no testcases (because some time ago I didn’t
  follow the TDD approach;) ). For nearly all modules in osc2 there exist
  testcases (white-box tests) thus it would be nice if we have some
  testcases for the cpio module, too (theoretically we could add some
  black-box tests (the current methods aren’t really testable thus
  white-box tests aren’t possible)).
• have a nice pythonic interface:
  The new interface will look like this:
  
from cpio import cpio_open
# let "f" be a file-like object (for instance a http response)
with cpio_open(fobj=f) as cpio_archive:
    for a_file in cpio_archive:
        # store file (with correct permissions etc.) in os.curdir
        a_file.write(os.curdir)
        # alternatively it's also possible to read some data (instead of
        # writing it to disc) via a_file.read(len)

  We will also support a plain filename in cpio_open.

Currently the cpio module will only support the “new ascii” (ascii SVR4
no CRC) format and regular files (that’s sufficient for our needs). But
it will be possible to simply pass in a class for a different format
(that is no code has to be altered in order to support a new format).

Finally this will be finished by the end of this week.
If you have any questions or suggestions please tell me:)

Marcus

[1] https://github.com/openSUSE/osc/blob/master/osc/util/cpio.py

Hi,

first of all I’m happy that I was accepted for GSoC again. The goal of this year’s project is to enhance
the existing osc2 library which was developed during last GSoC. Additionally I’m going to work on a new osc2 client. For the details have a look at the proposal (or just ask:) ).
Here’s a small summary of the first and second (coding) week. Unfortunately I was a bit busy with university (as usual…) and I just implemented the missing code for the “Request” class. Now it is possible to accept, decline etc. reviews and requests. Example

req = Request.find('123')
req.accept(comment='looks good')
# or accept the second review
req = Request.find('42')
review = req.review[1]
req.accept(comment='ok', review=review)

As usual the test driven development approach is used which worked quite good in the last year.
Todo for this week:

• add a build module to the osc2 library which can be used to build a package (basically a wrapper around the “build” script)