chiark / gitweb /
wip
authorIan Jackson <ijackson@chiark.greenend.org.uk>
Sun, 16 Aug 2015 19:35:41 +0000 (20:35 +0100)
committerIan Jackson <ijackson@chiark.greenend.org.uk>
Sun, 16 Aug 2015 19:35:41 +0000 (20:35 +0100)
moreinfo.fig [new file with mode: 0644]
talk.txt

diff --git a/moreinfo.fig b/moreinfo.fig
new file mode 100644 (file)
index 0000000..602a90b
--- /dev/null
@@ -0,0 +1,20 @@
+#FIG 3.2  Produced by xfig version 3.2.5b
+Landscape
+Center
+Metric
+A4      
+100.00
+Single
+-2
+1200 2
+0 32 #ffddaa
+2 1 0 2 0 7 50 -1 -1 4.500 0 0 -1 0 0 2
+        900 4860 11340 4860
+2 1 0 2 0 7 50 -1 -1 4.500 0 0 -1 0 0 2
+        900 810 2340 810
+4 0 0 50 -1 16 24 0.0000 4 300 1710 900 4680 More info\001
+4 0 0 50 -1 16 20 0.0000 4 315 10455 900 5490 start with dgit(1), dgit(7) from manpages.debian.net, or dgit.deb in testing\001
+4 0 0 50 -1 16 24 0.0000 4 300 1350 900 630 Thanks\001
+4 0 0 50 -1 16 20 0.0000 4 315 690 900 1350 Joey\001
+4 0 0 50 -1 16 20 0.0000 4 240 690 900 1890 DSA\001
+4 0 0 50 -1 16 20 0.0000 4 300 1350 900 2340 ftpmaster\001
index 5b0bc620f9b425840d9383bdd71aeb4a552740ee..c9e820cc21cae79b553e133f59bf7077f6d794d5 100644 (file)
--- a/talk.txt
+++ b/talk.txt
@@ -467,6 +467,22 @@ the git-buildpackage and git-dpm maintainers about this.  I'm
 optimistic particularly about git-buildpackage.
 
 
+There is a difficulty with empty directories in source packages.  git
+refuses to handle empty directories - they tend to just vanish from
+commits and checkouts.  But I'm told there are some source packages
+whose orig tarballs contain empty directories, and build systems
+depend on those empty directories.
+
+Currently if you dgit clone such a package, it won't build.  I don't
+have a particularly good answer to this problem right now.  It's no
+good to have dgit create these directories in the working tree, when
+it notices, because the git branches might be transported by plain git
+and used elsewhere.
+
+This can be worked around in the source package by either adding
+something to debian/rules to create these directories, or by adding
+some files to the directories to make them nonempty.  But at the
+moment a maintainer is not required to do either of these things.
 
 
 And then there are a couple of exciting possibilities for new uses:
@@ -474,7 +490,10 @@ And then there are a couple of exciting possibilities for new uses:
 Firstly, it would be very nice to have a way for a sponsee to provide
 a dgitish git branch, which the sponsor could work with directly and
 ultimately dgit push.  I'm really need to talk about this with some
-people more familiar than me with the sponsorship queue infrastructure.
+people more familiar than me with the sponsorship queue
+infrastructure.
+
+
 
 Secondly, dgit is not just for Debian.  Other distros currently using
 only source packages can use it too.  Read-only support doesn't
@@ -488,9 +507,23 @@ I hear rumours that Ubuntu might grow a dgit git server and support
 dgit push.  Patches very welcome!
 
 
-xxx==== Thanks and more info slide
+==== Thanks and more info slide
+
+Finally, there are some people I need to thank.
+
+At least half of the design of dgit is Joey Hess's, at the now-famous
+session in Vaumarcus.
+
+Debian System Administration, and particularly Peter Palfrader, have
+been absolutely brilliant.  The level of service and competence has
+been outstanding.  Ever time I noticed some aspect I had forgotten,
+and made a blatherous and ill-thought-out request, DSA would propose a
+much better alternative and implement their end of it it almost
+immediately.
 
-xxx thank dsa ftpmaster
+Also, I'd like to thank the ftpmasters for setting up the new
+ftpmaster data service.  This has enabled me to extend dgit's
+useability to non-DDs.
 
 
 So that's most of what I have prepared.  There's, of course, a lot