[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: debian-ports.org getting relatively unstable (hppa)



On 12/15/13 3:54 AM, Helge Deller wrote:
On 12/15/2013 06:32 AM, Dave Land wrote:
Not sure what's up at debian-ports.org, but I've been trying to
debootstrap 2 different HPPA machines for the last couple days and
have been getting a variety of errors (size mismatches, files not
found when they were there 20 minutes before, etc. etc.) Somebody may
want to look into this before it gets out of hand. Thanks! :)

I maybe should add some more background here, and maybe someone
here on the list might have an idea on how to proceed.

Background is, that Dave and myself have binmnu-uploaded the necessary
packages for hppa so that debootstrap worked. Then we proceeded with the necessary
packages for sbuild and schroot, so that I now have a buildd installed
which should be able to start building packages. I haven't turned it
on yet though for the reasons which I explain in a few seconds...

In the meantime we have of course uploaded a few more packages which
now currently break debootstrap. This is fixable manually, but I instead
of uploading packages manually now, I would prefer to get the buildd
going instead... So, Dave Land, please wait a little bit...

Now to the reasons why I didn't turned on the buildd yet:
We noticed, that when we manually binmnu-upload packages, which are
already in the *same version* on debian-ports, then debian-ports ACCEPT
those packages, but if we then try to apt-get-update those later on, this leads
to a "size mismatch" error. I do have the feeling, that this is a
problem on debian-ports. I noticed for example that reprepro usually
doesn't accept packages of the same version which doesn't seem to be
the case on debian-ports.
So, I'm anxious, that if I start the buildd, it will happily build and upload packages
which we already uploaded to debian-ports. If this happens we will get more
size-mismatch errors.

A trivial example:
On machine buildd.debian-ports.org I run:
deller@leda:~$ wb info hello . hppa
* hello/hppa
   | hello:
   |   Package             : hello
   |   Version             : 2.8-4
   |   State               : Needs-Build
   |   Section             : devel
   |   Priority            : source
   |   Previous-State      :
   |   State-Change        : 2013-02-18 00:03:36.782007
   |   CalculatedPri       : 52
   |   component           : main
   |   Distribution        : sid
   |   Notes               : out-of-date
   |   State-Days          : 300
   |   State-Time          : 25958430

So, the package "hello" would need a rebuild according to the wanna-build database,
and that would wb probably tell my buildd who then would start building/uploading it.
But on http://ftp.debian-ports.org/debian/pool-hppa/main/h/hello/ you can
see, that the hello-package is already uploaded at version 2.8-4
So, if my buildd now uploads the newly created hello package, I'm sure
we will run again into the size-mismatch problem.

Now, Aurelien mentioned last week to me, that this size-mismatch error
might be because of the "apt-ftparchive cache might have been corrupted for hppa".
I'm not 100% sure about that.

My question here on the list would be, if you (other arch-porters) do have an idea
on how I should proceed.
Best solution would probably be, if the wanna-build database rescans what's in
the archive already. Is this possible?
Or, should I just start the buildd and see what's happening? If we then get
the size-mismatch errors there is lot of manual work to fix it (unless resetting the
apt-ftparchive on debian-ports would solve this).
Any other ideas?

Helge


Thanks Helge,
I'll just put the A500 on standby for a while until things stabilize a bit. I saw Thorsten Glaser's comments over in the debian-ports list, and although it doesn't make a whole lot of sense to me, since I don't fully understand how packages get processed at the repository when the buildd server uploads (or somebody manually uploads). It seems odd that debian-ports would accept a package with the same name/version number... unless it's looking at the md5 signature instead of the filename?? Is that even possible? I would think those would be unique for each file uploaded. Might be a solution to rework things where the server would look at the filename *and* the md5 sig to determine if the filename would need to be auto-incremented to the next iteration/update (e.g. hello-2.1.1-1 to hello-2.1.1-2)

Just a thought... I'll check back later. :)

Dave L.

--

--
Dave Land
Land Computer Service  xmechanic@landcomp.net
ICQ: 676030523



Reply to: