Re: Packages stuck in Built

[Wouter Verhelst]

Hi,

On Mon, Jul 20, 2015 at 10:03:21PM +0200, Joachim Breitner wrote:
> Hi,
> 
> Am Montag, den 20.07.2015, 19:16 +0200 schrieb Joachim Breitner:
> > in this case, I found that there was a partial upload in
> > ftp://ftp.upload.debian.org/pub/UploadQueue/
> > I issued the dcut rm commands to remove the files.
> > 
> > I also found two more affected packages (haskell-wai-app-static and
> > haskell-yesod-form).
> > 
> > Will buildd retry the upload automatically?
> 
> The partial upload is back. Something seems to be broken with this
> builder, so I am  escalating this to powe...@buildd.debian.org:
> Uploading haskell-tagstream-conduit, haskell-wai-app-static and
> haskell-yesod-form seems to fail.

Yeah, praetorius has been spamming me with "dupload failed" mails since
sunday or thereabouts. I've tried fixing it, but it's a more complex one
than usual and it required more than I had time for last sunday (and I
forgot about it yesterday).

I'll look at gettings things unstuck now.

-- 
It is easy to love a country that is famous for chocolate and beer

  -- Barack Obama, speaking in Brussels, Belgium, 2014-03-26


signature.asc
Description: Digital signature

Re: no change - why? Re: please rebuild mgltools-sff

[Wouter Verhelst]

On Sat, Aug 18, 2012 at 08:46:57PM +0200, Steffen Möller wrote:
> On 08/18/2012 08:28 PM, Wouter Verhelst wrote:
> > On Sat, Aug 18, 2012 at 08:27:53PM +0200, Wouter Verhelst wrote:
> >> On Sat, Aug 18, 2012 at 07:45:00PM +0200, Steffen Möller wrote:
> >>> The formerly missing dependency mgltools-bhtree should just be fine.
> >>> http://packages.qa.debian.org/m/mgltools-sff.html
> >>
> >> Done.
> > 
> > That is, given back. It should be built some time soon.
> > 
> Here it is
> https://buildd.debian.org/status/package.php?p=mgltools-bhtree
> but all I get is
> https://buildd.debian.org/status/package.php?p=mgltools-sff

Yes, I was actually expecting that.

It doesn't say "build-dep", it says "BD-Uninstallable". That's an
automated process which checks build-dependencies for installability.

Why it's claiming that, though, I couldn't tell. A quick check does show
that mgltools-bhtree is available (in non-free) for powerpc, yet when I
add non-free to a sources.list file on a powerpc sid chroot, it doesn't
even find it (though it does find the source).

I'm probably missing something. Adding wb-team to Cc, maybe they've got
a clue?

-- 
The volume of a pizza of thickness a and radius z can be described by
the following formula:

pi zz a


-- 
To UNSUBSCRIBE, email to debian-wb-team-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120818195802.gc25...@grep.be

Re: powerpc: leptonlib stuck in "Built" state

[Wouter Verhelst]

On Sun, Jul 29, 2012 at 12:10:06PM -0500, Jonathan Nieder wrote:
> Hi,
> 
> Based on [1], leptonlib was built on praetorius 8 days ago but
> never got uploaded.  Known problem?  Does it need any nudging
> to get put into place?

Apparently the mail never reached my mailbox. Another reason why I
really really need to work on getting autosigning set up for praetorius,
but that requires some other work first.

Anyway, I just signed it, it should be uploaded Soon(TM).

-- 
The volume of a pizza of thickness a and radius z can be described by
the following formula:

pi zz a


-- 
To UNSUBSCRIBE, email to debian-wb-team-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120729193732.ga22...@grep.be

Re: Meeting Minutes, FTPMaster meeting March 2011

[Wouter Verhelst]

On Mon, Mar 28, 2011 at 10:19:32PM +, Philipp Kern wrote:
> On 2011-03-28, Wouter Verhelst  wrote:
> > But I'd think that "making sure this buildd host can still do uploads in
> > a timely manner when the key expires" is pretty well inside the realm of
> > the buildd admin's responsibility.
> 
> And manual signing wouldn't be timely?

Less so.

> I talked with Joerg at the meeting and we agreed that arch-based admin
> keyrings aren't needed.  If you feel so strongly about it, I think you
> should take it up yourself and make [0] support one keyring per arch.
> (Or get Joerg to do it.  As I told him that he doesn't need to consider
> it in the initial design it feels unfair to me to ask him now.  Either
> way, if it isn't done, you don't feel strongly enough about it.  There's
> no policy decision in the way this time.)

Sure; I'd be happy to put my code where my mouth is, if that helps solve
this particular issue. It'll have to wait until my current move is over,
however (see my [vac] on -private). 

Note that it isn't entirely clear to me how splitting up keyrings per
architecture would help there, so some explanation might help (if I want
to make sure that whatever patch I come up with actually solves the
issue at hand...).

> I still don't think it's necessary, as it will be mostly identical on
> all archs and we'll be doing the work anyway but frankly I don't care,
> as long as the keys are following the rules the ftp-masters set for
> them.  We'll still monitor the expiry and if you don't react quickly
> enough do it ourselves.

Of course.

-- 
The biometric identification system at the gates of the CIA headquarters
works because there's a guard with a large gun making sure no one is
trying to fool the system.
  http://www.schneier.com/blog/archives/2009/01/biometrics.html


signature.asc
Description: Digital signature

Re: Meeting Minutes, FTPMaster meeting March 2011

[Wouter Verhelst]

Hi Phil,

[ Note: re-reading, I find that my mail could be read as "heated", which
it wasn't meant to be. I'm firm in what I believe needs to be done, but
not angry :-) ]

On Mon, Mar 28, 2011 at 03:08:12PM +0200, Philipp Kern wrote:
> > So, AIUI, only members of the wbadm GID can change keys, not any random
> > buildd admin.
> > 
> > If I'm supposed to be maintaining a buildd host, I should be able to
> > update the key allowed for signing, or I can't do my job properly. We've
> > had a situation where only a limited group of people could activate
> > buildd machines in the past, and it was broken; I have no desire to get
> > back to that situation.
> 
> AFAIR you were against autosigning on your buildds.  So nothing will change
> for you anyway, unless you allow it.

You may remember from your wanna-build BOF during dc10 that I said
something along the lines of "yes, I know I said I was against it. I
changed my mind." :-)

> As Joerg said, we still have that problem because only gid=wbadm can
> change the ssh keys on grieg.

I wasn't aware of that; I was under the impression that I could update
ssh keys when and if I needed to.

You're not helping :-)

> And only gid=ftp-master can change the list for the hosts allowed to
> access incoming.  (To be fair: DSA now exports a list of d.o buildds
> to ftp-master to automatically allow access to ftp-master's incoming
> directory and to security-master.) And you need the machine installed
> with the buildd profile by DSA in the first place.

Sure. There's always going to be some things I can't do, if we want the
machine to be running properly (that is, unless I become a member of the
appropriate teams, but given my current time constraints that isn't very
likely).

But I'd think that "making sure this buildd host can still do uploads in
a timely manner when the key expires" is pretty well inside the realm of
the buildd admin's responsibility.

> > Please fix this by doing one of
> > - Adding me (and other buildd admins) to the wbadm group,
> > - Creating a new GID to which all buildd admins are added (I'd suggest
> >   'builddadm' for that, but apparently that's already taken and is 100%
> >   the same as wbadm; if that isn't used, however, it could make sense)
> >   which would limit who can update keys
> > - Changing the GID to "Debian", rather than anything else (I don't think
> >   you lose much by doing that, but I guess there might be reasons not
> >   to, and it's not my call anyway)
> > - Finding someone else to maintain praetorius and voltaire
> 
> The purpose of the wbadm group is the maintainance of the central
> wanna-build host.  We also control who accesses our infrastructure and
> how.  That's already the case since years.  Do you have any complaint
> about the request turnaround time there?

Not currently.

However, I was not initially complaining about the request turnaround
time back when the wanna-build team consisted mostly of James and Ryan,
either. But eventually that changed, and I got very very very frustrated
with that[1]. When the buildd stuff was changed so that many more people
got involved, I was hoping that this kind of thing would never happen
again.

Now I'm not saying that every buildd admin should have full and
unlimited access to wanna-build.d.o, or that we should all be
responsible for maintaining the wanna-build software (i.e., I'm not
suggesting to make wbadm and the set of buildd admins be one and the
same group). But I do think that when you add a new responsibility, you
should figure out whether this responsibility is in the realm of the
buildd admin or not. I believe that this one is, and therefore I should
be able to do it myself without requiring outside intervention.

As said, usually the request turnaround time is very reasonable, and I
have no complaints there. But there have been times where it was
slightly longer than average, and adding more things on the heap of
stuff which only you guys can do isn't helping. And, really, when a key
rollover needs to be done, most of the work is "gpg --gen-key", and
scp'ing the public key to the right system. If I can do all that, but
need one of you to run "mv $key $targetloc", that's just adding needless
bureaucracy. I want to avoid that, because I don't believe it makes
sense.

If the fear is that people will add keys without following proper
procedure, then please document the procedure in a way which makes it
hard to miss, and by all means bitchslap those who fail to follow
procedure properly. The set of "buildd admins" is small enough that
this should be workable. But I don't think it makes sense to take an
already limited group of people (buildd admins) and limit them even
further for things that lie squarely in their area of responsibility.

I don't really care about SSH keys, because they don't change (unless
someone breaks in and steals them, but then I expect DSA to step in,
lock down the host, do forensics, reinstall, etc, and eventually
generate a new SSH key while

Re: Meeting Minutes, FTPMaster meeting March 2011

[Wouter Verhelst]

On Mon, Mar 28, 2011 at 01:26:02PM +0200, Joerg Jaspert wrote:
> Hi
> 
> >> - The long standing project of enabling autosigning for the buildds also
> >>   got finished. That means that packages successfully built can now be
> >>   uploaded automatically, without waiting for the buildd admin to wake
> >>   up/come back from holiday/whatever. The rules for this are simple
> >>* the buildd host must be maintained by DSA and have restricted
> >> access
> >>* the key must have a size of 4096 or higher and the private part
> >>  must never leave the buildd
> >>* the key expires within 120 days
> >>* there are not more than 2 keys per buildd (so they can do a key
> >>  rollover)
> >>* no network access during build time/for the build part
> >>   We maintain a set of keyrings, one per architecture, together with a
> >>   shell script which allows the wanna-build admins to add and remove
> >>   keys as necessary.
> > So, AIUI, only members of the wbadm GID can change keys, not any random
> > buildd admin.
> 
> Correct.
> 
> > If I'm supposed to be maintaining a buildd host, I should be able to
> > update the key allowed for signing, or I can't do my job properly. We've
> > had a situation where only a limited group of people could activate
> > buildd machines in the past, and it was broken; I have no desire to get
> > back to that situation.
> 
> You can do your job properly and you can activate buildd machines.
> What you can not get is an added feature on top slightly easing the
> workload. I don't think this can seriously be called "unable to do the
> job properly".

Many improvements in Debian start out as an "added feature on top
slightly easing the workload". Wanna-build started out as a way to not
have to run quinn-diff manually. Buildd started out as a way to not have
to run sbuild manually. Sbuild started out as a way to not have to run
dpkg-buildpackage... well, you get the idea.

It's not required today, that much is true. In two years' time, people
will have mostly forgotten about these manually-maintained buildd hosts,
and will complain when their pet package isn't uploaded into the archive
yet, five minutes after build.

(heck, they do so now, occasionally, even without autosigning)

> Now, this feature does require a whole set of people to do work before
> (for example DSA to have the machine DSA maintained and secured up,
> getting the ssh keys and w-b access for the buildd, getting access to
> incoming to build stuff from there), and so I really fail to see where
> "When asking for ssh/incoming/w-b access, get them to prepare the
> autosign key" is much of added trouble?

That in itself isn't, no. But the key rollover bit (which is senseble,
btw; I'm not suggesting you remove that requirement) does make it a
problem.

> > Please fix this by doing one of
> > - Adding me (and other buildd admins) to the wbadm group,
> 
> None of ftpteams call.

Sure.

> > - Creating a new GID to which all buildd admins are added (I'd suggest
> >   'builddadm' for that, but apparently that's already taken and is 100%
> >   the same as wbadm; if that isn't used, however, it could make sense)
> >   which would limit who can update keys
> 
> Also none of ftpteams call, we dont change other peoples groups.

I'm not asking to change other people's groups, here, just that "some
other group" is used. If builddadm is used for something else and that
can't be rolled into wbadm (which seems to be the case), then something
else should be used.

The point is that a buildd admin should be able to update the necessary
bits for his buildd to function properly, if the bits are broken.
Otherwise you don't need a buildd admin.

> > - Changing the GID to "Debian", rather than anything else (I don't think
> >   you lose much by doing that, but I guess there might be reasons not
> >   to, and it's not my call anyway)
> 
> Now this won't happen.

fair enough.

> > - Finding someone else to maintain praetorius and voltaire
> 
> Not my call either, even though I do think that putting it onto this single
> feature is a bit over the top.

That's your choice, but I do have my reasons.

> Basically this is something the people on the buildd site have to fight out
> between. What we on the ftp side want is a *limited* set of people who can do
> keychanges, that isn't changing too often.

This makes sense.

> wbadm does seem to be a perfect fit for this.

This I disagree with.

> > For clarity, the last option is *not* my preference. However, if none of
> > the other three are done, I'm no longer interested in spending my time
> > doing something I can't do properly anyway. I've been forced to work
> > around not being able to fix issues with connectivity between my buildd
> > host and the rest of the Debian infrastructure in the past, and I won't
> > stand for it anymore.
> 
> See above. This is an *additional* thing, any buildd will be able to run even
> without this (and someone mentioned you don't like this feature

Re: Meeting Minutes, FTPMaster meeting March 2011

[Wouter Verhelst]

On Sun, Mar 27, 2011 at 10:56:28AM +0200, Joerg Jaspert wrote:
> - The long standing project of enabling autosigning for the buildds also
>   got finished. That means that packages successfully built can now be
>   uploaded automatically, without waiting for the buildd admin to wake
>   up/come back from holiday/whatever. The rules for this are simple
>* the buildd host must be maintained by DSA and have restricted access
>* the key must have a size of 4096 or higher and the private part
>  must never leave the buildd
>* the key expires within 120 days
>* there are not more than 2 keys per buildd (so they can do a key
>  rollover)
>* no network access during build time/for the build part
> 
>   We maintain a set of keyrings, one per architecture, together with a
>   shell script which allows the wanna-build admins to add and remove
>   keys as necessary.

So, AIUI, only members of the wbadm GID can change keys, not any random
buildd admin.

If I'm supposed to be maintaining a buildd host, I should be able to
update the key allowed for signing, or I can't do my job properly. We've
had a situation where only a limited group of people could activate
buildd machines in the past, and it was broken; I have no desire to get
back to that situation.

Please fix this by doing one of
- Adding me (and other buildd admins) to the wbadm group,
- Creating a new GID to which all buildd admins are added (I'd suggest
  'builddadm' for that, but apparently that's already taken and is 100%
  the same as wbadm; if that isn't used, however, it could make sense)
  which would limit who can update keys
- Changing the GID to "Debian", rather than anything else (I don't think
  you lose much by doing that, but I guess there might be reasons not
  to, and it's not my call anyway)
- Finding someone else to maintain praetorius and voltaire

For clarity, the last option is *not* my preference. However, if none of
the other three are done, I'm no longer interested in spending my time
doing something I can't do properly anyway. I've been forced to work
around not being able to fix issues with connectivity between my buildd
host and the rest of the Debian infrastructure in the past, and I won't
stand for it anymore.

Thanks,

-- 
The biometric identification system at the gates of the CIA headquarters
works because there's a guard with a large gun making sure no one is
trying to fool the system.
  http://www.schneier.com/blog/archives/2009/01/biometrics.html


signature.asc
Description: Digital signature

Re: Giving back to a particular buildd

[Wouter Verhelst]

On Mon, Jun 28, 2010 at 11:26:21PM +0200, Kurt Roeckx wrote:
> On Mon, Jun 28, 2010 at 08:36:18PM +0200, Joachim Breitner wrote:
> > Hi,
> > 
> > the Haskell team maintains (besides a lot of unproblematic) a handful of
> > package that require a lot of resources (mostly RAM) when building. On
> > some architectures, these packages can only be built by certain buildds,
> > while they are failing on others. So far, I have observed buildd admins
> > just repeatedly giving back packages in question until the "right"
> > buildd machine picked it up.
> 
> What I have noticed on hppa is that ghc is just taking 100% CPU
> time all the time.  Trying it on a different buildd is unlikely
> to change the result, and setting the timeout higher is also
> unlikely to be helping.  All hppa buildds have 4 GB ram or more and
> I've only seen ghc use like 250 MB.  I have no idea what the problem
> is, but just retrying clearly isn't helping.
> 
> Not sure what the status is on other arches.
> 
> > Would it be possible to improve this situation? I don't know that part
> > of the wanna-build suite (nor any of the sbuild/buildd code), but I
> > could imagine either
> >  * a field in the database, optionally specifying for each source
> > package/arch tuple, the list of buildds that are allowed to take the
> > source
> 
> We currently don't have this option.  And this is probably
> something useful to have.
> 
> > or
> >  * a local bit of configuration on the buildd site, listing packages
> > that _this_ buildd should not build.
> 
> We have this option now, but it's only used for a small amount of
> problematic packages.
> 
> > Which would fit the general scheme of things better? Does wanna-build
> > decide who gets to build what, or do the buildds pick their choice of
> > package? I'd probably try to provide a patch when I'm pointed in the
> > right direction.
> 
> buidd does wanna-build --list=needs-build, buildd then takes the
> first of that list that isn't in it's exclude (or low priority)
> list.

I believe it did wanna-build -U buildd_arch-host --list=needs-build,
actually. And if it doesn't, it should be fairly straightforward to make
it do that and have wanna-build not list some packages if the "wrong"
user was used.

-- 
The biometric identification system at the gates of the CIA headquarters
works because there's a guard with a large gun making sure no one is
trying to fool the system.
  http://www.schneier.com/blog/archives/2009/01/biometrics.html


-- 
To UNSUBSCRIBE, email to debian-wb-team-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100725215337.gx4...@celtic.nixsys.be

Re: force-confnew (was: Document correct buildd chroot setup somewhere?)

[Wouter Verhelst]

On Mon, Apr 05, 2010 at 08:36:16PM +0200, Philipp Kern wrote:
> This doesn't mean that we shouldn't fail on obvious bugs in a package.
> I'm just not sure if we should allow bystanding packages that happen
> to be pulled in somewhere (and not being uninstalled/purged) to screw up
> the build process *in a non-deterministic way*.

Except that it's not actually nondeterministic.

Missing build-conflicts are just latent packaging bugs; while we don't
guarantee that they don't exist, having the ability to detect them, even
as a byproduct of some other process, is a good thing, IMHO.

At any rate, there are many ways in which buildd/sbuild can fail. This
is just one of them; and that is why we have a human handling the
output, rather than make it an automated process.

-- 
The biometric identification system at the gates of the CIA headquarters
works because there's a guard with a large gun making sure no one is
trying to fool the system.
  http://www.schneier.com/blog/archives/2009/01/biometrics.html


-- 
To UNSUBSCRIBE, email to debian-wb-team-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100506124401.gk3...@celtic.nixsys.be

Re: please give back hal 0.5.13-6 on powerpc

[Wouter Verhelst]

On Sat, Nov 28, 2009 at 07:33:22AM +0100, Michael Biebl wrote:
> Hi,
> 
> hal_0.5.13-6 is in state Building since 3 days already on powerpc. I guess
> it's time to try again.

Malo went berserk, again. I'm fixing it now, and will give back all
packages.

Sorry 'bout the delay, I was busy.

-- 
The biometric identification system at the gates of the CIA headquarters
works because there's a guard with a large gun making sure no one is
trying to fool the system.
  http://www.schneier.com/blog/archives/2009/01/biometrics.html


signature.asc
Description: Digital signature

Re: give back bluez on mips(el), wait for binutils 2.20-3?

[Wouter Verhelst]

On Thu, Nov 12, 2009 at 07:23:37PM +0100, Luk Claes wrote:
> Simon McVittie wrote:
> > On Thu, 12 Nov 2009 at 07:21:30 +0100, Luk Claes wrote:
> >> Simon McVittie wrote:
> >>> dw bluez_4.56-2 . mips mipsel . -m 'binutils (>= 2.20-3)'
> >> Scheduled.
> >>
> >>> gb bluez_4.56-2 . mips mipsel
> >> Bogus, so not tried: wanna-build commands are usually used to change the
> >> status of a package. Why would you want to change it from Dep-Wait to
> >> Needs-Build, that does not make any sense to me as that would throw away
> >> the Dep-Wait which was just been set.
> > 
> > Sorry, I don't really know how the internals of wanna-build work, or how the
> > commands interact with them. After reading
> >  and
> >  it was reasonably
> > clear to me that bluez needed a dep-wait on binutils, but it wasn't clear
> > whether I'd also need to specify gb in order to prod w-b into doing 
> > something.
> > 
> > I'll try to construct a patch against wanna-build.txt and/or 
> > wanna-build-states
> > that would have made it clearer what I should do. I assume the contact 
> > address
> > is debian-release for the former, or debian-www cc debian-wb-team for the
> > latter?
> 
> Thanks already. Yes, the contact addresses look right to me.

Actually, I more or less try to maintain the latter, so I'd appreciate
being explicitly kept in the loop on that one -- but of course the
website is the responsibility of -www, to which I'm subscribed (as a
lurker)

-- 
The biometric identification system at the gates of the CIA headquarters
works because there's a guard with a large gun making sure no one is
trying to fool the system.
  http://www.schneier.com/blog/archives/2009/01/biometrics.html


-- 
To UNSUBSCRIBE, email to debian-wb-team-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

buildd.d.o down?

[Wouter Verhelst]

Hi,

Looks like buildd.d.o is down, and has been so since (at least)
yesterday evening.

What's going on?

-- 
The biometric identification system at the gates of the CIA headquarters
works because there's a guard with a large gun making sure no one is
trying to fool the system.
  http://www.schneier.com/blog/archives/2009/01/biometrics.html


-- 
To UNSUBSCRIBE, email to debian-wb-team-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Package signing delays

[Wouter Verhelst]

On Mon, Sep 07, 2009 at 06:31:25AM +0200, Andreas Barth wrote:
> What I personally would like is that packages are generally uploaded
> within 24 hours after the buildd log is sent, and also they are
> generally uploaded within 3 days after the source package is uploaded
> / binNMU is requested (the second being more some "what it means to
> say the buildds are fast enough").
> 
> Does this sound sensible?

It does to me. In fact, I suggested the very same thing a few times
during the last DebConf.

-- 
The biometric identification system at the gates of the CIA headquarters
works because there's a guard with a large gun making sure no one is
trying to fool the system.
  http://www.schneier.com/blog/archives/2009/01/biometrics.html


-- 
To UNSUBSCRIBE, email to debian-wb-team-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: trend build issues

[Wouter Verhelst]

On Tue, Sep 01, 2009 at 04:07:28PM +0200, Philipp Kern wrote:
> On Tue, Sep 01, 2009 at 01:55:06PM +0200, Yuri D'Elia wrote:
> > On a side note, can you please document the "BD-Uninstallable" state in
> > the Debian website?
> > 
> >   http://www.debian.org/devel/buildd/wanna-build-states
> 
> Probably we should, yes.

On it.

-- 
The biometric identification system at the gates of the CIA headquarters
works because there's a guard with a large gun making sure no one is
trying to fool the system.
  http://www.schneier.com/blog/archives/2009/01/biometrics.html


-- 
To UNSUBSCRIBE, email to debian-wb-team-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Please do not idly mess with packages in state Building

[Wouter Verhelst]

Hi,

This morning, when I signed the mails from voltaire and malo, I received
one response from voltaire that said that it didn't have OpenOffice.org
taken for building, but that instead it was marked as Dep-Wait.

Investigating turned up that this was manually modified by a person from
the release team who really should've known better[1]. OpenOffice.org
takes over a day to build[2], and the last thing I need is for it to be
built twice because someone made a silly mistake.

It's not the first time something like this happens; there have been
several cases where I sign something like 20 mails in the morning, and
say 5 of them come back with "this package is already installed" or
"this package isn't taken for building by you, but by ",
or something similar. 

I'd really like to request that if you're dealing with a package in
state Building, you be more careful. The whole point of wanna-build is
to avoid double work, but that's subverted if things like this happen.

Of course there are exceptions. If a package has been in Building for
weeks or months, fixing that is called 'cleanup', and absolutely
welcome. If a package is in state Building but has the wrong
build-dependencies or is involved in a transition or some such and you
don't want it to be built just yet, I guess that's okay too, but please
talk to us then, so we know what's going on.

In all other cases, please do not touch packages in Building and assume
that the build will work until proven otherwise, or go check on the
buildd itself what the current state is.

Thanks,

[1] This mail is not about finger pointing, so the guilty shall remain
unnamed. If you really must, go look at the logs.
[2] Build started at 20090831-1340
[...]
Finished at 20090902-0009

I.e., 35 hours and 29 minutes.

-- 
The biometric identification system at the gates of the CIA headquarters
works because there's a guard with a large gun making sure no one is
trying to fool the system.
  http://www.schneier.com/blog/archives/2009/01/biometrics.html


signature.asc
Description: Digital signature

Re: Dep-wait for vlc on sparc

[Wouter Verhelst]

On Sat, Jul 25, 2009 at 04:03:29PM +0200, Kurt Roeckx wrote:
> On Fri, Jul 24, 2009 at 11:40:31PM +0200, Christophe Mutricy wrote:
> > Hello,
> > 
> > libc6-dev 2.9-20 is missing scsi/scsi.h which is needed to compile vlc.
> > So we need to wait for libc6-dev 2.9-21 before retrying to build vlc on
> > sparc.
> > 
> > dw vlc_1.0.0-1 . sparc . -m 'libc6-dev (>=2.9-21)'
> 
> A dep-wait won't help.  The chroot first needs to be updated
> manually.

It will, provided the package build-depends on the fixed version of
libc6-dev. Whether that is a good idea, however, depends on other
things.

-- 
The biometric identification system at the gates of the CIA headquarters
works because there's a guard with a large gun making sure no one is
trying to fool the system.
  http://www.schneier.com/blog/archives/2009/01/biometrics.html


-- 
To UNSUBSCRIBE, email to debian-wb-team-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: [PATCH 2/5] Implement locking for other process

[Wouter Verhelst]

On Fri, Jul 24, 2009 at 03:16:43AM +0200, Joachim Breitner wrote:
> Locking for another process means that a longer running process (most likely
> wb) wants to do several steps at once, and manages the locks.
> 
> Added parameters are:
> --lock-for PID: Locks the database for the process with this pid
> --unlock-for PID: Unlocks the database for the process with this pid
> --act-on-behalve-of PID: Ignores the log (if it is held by this pid)

In order not to confuse people, you should probably use
'act-on-behalf-of', which is the correct English version. 'behalve'
sounds like a combination of "beheaded" and "two halves" or some such.

-- 
The biometric identification system at the gates of the CIA headquarters
works because there's a guard with a large gun making sure no one is
trying to fool the system.
  http://www.schneier.com/blog/archives/2009/01/biometrics.html


-- 
To UNSUBSCRIBE, email to debian-wb-team-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

wb brokenness

[Wouter Verhelst]

Hi,

[dato in Cc, since he appears to have written it and I'm not sure he's
subscribed to this mailinglist]

When I first subscribed to this mailinglist, I was surprised to see all
those weird syntaxes flying by that I hadn't heard of before. So when
asked, Luk told me that it's a wrapper with an (according to him)
"easier syntax". Allow me to disagree, but that's not what this mail is
about (hey, you should use whatever *you* think is easiest, even if I
like the original interface).

There's a pretty important feature in wanna-build, called
'--pretend-avail', which is meant to fix up broken build-deps. The only
other option (that I'm aware of) to remove an incorrect build-dependency
in the wanna-build db, is to use '--forget' to remove the package from
the database and then to wait until it is repopulated, but this *will*
cause data loss. Since I am one of those weirdos who actually likes his
data, I would like to see that this is not used unless absolutely
necessary -- if I, for instance, mark a package as 'failed; triggers
ICE', I may want to not retry the package unless I believe there is a
reasonable chance that the ICE is fixed, or the wanna-build queue is not
too long, or something similar. This information, however, is thrown
away when the --forget option is used. Hence the importance of the
--pretend-avail option to wanna-build.

Apparently, however, if I read the code correctly[1], your wanna-build
wrapper does not support this important feature.

Can this please be fixed, and the feature be used?

Thanks,

[1] Since it was written in Python, which I despise, it may be that I'm
just missing something, in which case that's just fine, of course. I
think not, however.

-- 
The biometric identification system at the gates of the CIA headquarters
works because there's a guard with a large gun making sure no one is
trying to fool the system.
  http://www.schneier.com/blog/archives/2009/01/biometrics.html


-- 
To UNSUBSCRIBE, email to debian-wb-team-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Request for konversation give back on powerpc

[Wouter Verhelst]

On Tue, Jul 21, 2009 at 08:20:44PM +0300, Modestas Vainius wrote:
> konversation got into a bogus "Dep-Wait: libboots-program-options1.34.1" 
> state 
>   ^
>   typo
> on powerpc. I don't know where that Dep-Wait is coming from, but please
> remove it and give the package back.

That'd be me manually typing stuff rather than copy-pasting, I guess.
Sorry.

-- 
The biometric identification system at the gates of the CIA headquarters
works because there's a guard with a large gun making sure no one is
trying to fool the system.
  http://www.schneier.com/blog/archives/2009/01/biometrics.html


-- 
To UNSUBSCRIBE, email to debian-wb-team-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org