[Top][All Lists]

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

Re: RFC: upstreaming debian/patches/exec_filename_* and the dde stuff

From: Justus Winter
Subject: Re: RFC: upstreaming debian/patches/exec_filename_* and the dde stuff
Date: Mon, 07 Apr 2014 00:26:29 +0200
User-agent: alot/0.3.4


Quoting Samuel Thibault (2014-04-06 21:25:42)
> Justus Winter, le Sun 06 Apr 2014 19:58:45 +0200, a écrit :
> > I'd like to see more of the debian/patches merged, especially the
> > exec_filename_* series.
> The discussion about it with Roland was unfortunately not finished.

Please enlighten me.  I wasn't around when this was discussed, and I
tried to find the discussion but failed.  Meanwhile, I improved the
exec_filename_* series and fixed the fakeroot translator.  The
fakeroot translator is somewhat less useful w/o that patch series, so
I'd like to see this merged.

> >  I'd also like to see the dde stuff from the incubator repository
> > merged upstream.
> For this one, I'd like to avoid having to let userland processes disable
> interrupts, since this brings IRQ sharing issues.

Why does that prevent the merge?  We have plenty of stuff in the repo
that doesn't work, bitrots or is otherwise in a bad shape.  If someone
doesn't like the idea of letting userspace processes disable
interrupts, let her just not use the dde drivers.

> > may I change the API of, say, libports freely?
> Well, there is not only dde, but all incubator projects, as well as
> hurdextras, etc.
> > what is the best way to proceed?
> You can commit the dde-related changes in the incubator at the same
> time, both will be pulled at the same time in Debian updates, for
> instance.

How exactly is it that it is pulled in the Debian updates?  Manually
by you, I presume?

There's one thing that really bugs me.  I thought I stated this
before, or even in the original mail, but maybe it didn't came across

For me, building the Hurd is like driving rusty nails into ones knee,
only less fun.  It has caused me so much pain, that I created a
continuous integration solution that builds Debian packages.  ci is
nice and stuff, but ultimately I just wanted to relieve the pain.

Why is it painful?  Because Debian/Hurd is patched beyond recognition.
Clone the Hurd repository, build some component, say one of the core
servers, put it into your Debian installation and voila, your system
hangs at boot time.  So you clone the Debian/Hurd packaging repo,
which is a weird frankenstein-repo.  The upstream repo is mixed with
parts of the dde branch from the incubator, on top of that lives a
long list of debian/patches, some of them also carry dde stuff in
them.  You patch some stuff, try to build it, and surely enough you
need to refresh some debian/patches.  See here for the difference of
the Debian packaging repo and the hurd upstream repo:


So I got myself a solution for this problem.  I automated every step
that can possibly be automated, but I still have to amend the patches
in there often, like this:


Building half a Hurd package takes ~30 minutes using my solution.  My
workflow goes roughly like this:

1. come up with a patch against hurd upstream
2. add it to the patch series in my debian packaging repo
3. start a build
4. see my patch break b/c some other debian/patch also touches some
   file that my new patch touches
5. amend either mine or the other patch
6. goto 3

I do this for every patch series I propose.  Once the package is
built, it is uploaded to my deb repo and my test vm automatically
installs the new packages and verifies that the system still works.

The amount of time I still spend on just building debian packages is
mind-boggling.  If I wasn't the masochist I am, I would have stopped
doing that a long time ago.  Also, the way it is now it will never be
possible to fully-automatically build Debian packages from the Hurd

Today it got worse.  The package built fine, but surely enough all the
dde components broke apart at runtime b/c I changed the API of
libports.  The dde components that either are in the debian package
repo or in the debian/patches in the debian package repo, I don't even
know for sure.  Sure, I can fix those components up in the incubator
repo.  It was mostly an awareness problem. But then what?  How exactly
are they then "pulled" into my build solution?  How am I supposed to
test that I didn't break anything?  If I figure out how you create the
patches from the incubator repo, I could do that too.  In the end, we
still end up duplicating the packaging effort.  By the way, you'll
need fe9c72e60a59 too for the next Hurd package.

This has caused me so much pain.  And I imagine it is even worse for
new developers.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]