Hi, 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 clearly. 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: http://darnassus.sceen.net/gitweb/teythoon/packaging/hurd.git/tree 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: http://darnassus.sceen.net/gitweb/teythoon/packaging/hurd.git/commitdiff/fe9c72e60a59109bff7558224871ac5e80b9f38d 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 repository. 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. Justus
