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

Re: Working with gbp and older releases



Am Samstag, den 22.02.2014, 12:21 +0100 schrieb Dariusz Dwornikowski:
>  
> > A suggestion: You should the RFS Bug to get a broader audience, maybe
> > someone who can indeed sponsor.
> 
> Yes, I thought it would be better to share first with you, since you
> seemed interesed. 

Ok, just keep in mind that as I cannot sponsor
(but it seems your DM advovate had sponsored you already in the past, so
probably no RFS needed.)
> > -> Please file a bug for your changelog entry "Several security bugs" to
> > document in the BTS that the current version in xxx has problems. 
> > (One bug is enough, just quote your 5-lines in the changelog as bug
> > report)
> 
> Did that, thank you.
+1 ( I just added the securitiy tag and raised its severity)

For the rest of this, I pulled the latest git version... So I might be
wrong if not everthing was pushed...

> > If you bump the SV, you should not if there have been any changes
> > necessary and if not document that too.

Probably you missed that one :) ... (btw, SV = Standard Versions) 

> > Generally, d/changelog entries should reflect *what* have been changed
> > on not focus on the *why* something has changed. For example, you write
> > "We no longer modify the config (Closes: #710903)": 
> > I would write "updated d/postinst to no longer modifiy conffiles.
> > (Closes: #...)
> > (and in the patch for it, do not just comment out the lines, remove them
> > to be clear that this is not acciedentially commented out)
> 
> Done. Thank you. 
You might want to do that also for some other entries, not only the
example I quoted ;-)


> > (BTW, in this commit you change the dependency of duende to an *older*
> > version? As this looks weird, I *suppose* this is wrong... Maybe you
> > wanted to enforce the current version, then use ${binary:Version})
> 
> Fixed that. Thank you. 

Did you push that change? 


> > 
> > I see also that there are sometimes undocumented changes, please
> > document them. For example you updated the watchfile, add gpg signatures
> > but this is not documented in the d/changelog. But this is just an
> > example, there are more than this one. 
> 
> I got rid of that because it did not work. 

OK, I understand that... it's uscan... However, please see the
attachment, this version works here :)

(but do a git rm debian/upstream-signing-key.asc as you have the key two
times in the repository) 

> > 
> > d/control:
> > Why is the Breaks / Replaces necessary for maradns-zoneserver and other
> > packages? Why does the docs breaks an older version of maradns?
> 
> This
> Breaks/Replaces was some technique of the old maintainer. I removed it
> and it works fine without it. I think it was because of him updating
> conffiles in d/postinst, which got the package to violate the policy. 

Mmm... Checking the git repository, it seems that this was due to the
fact that maradns was split into several packages after 1.4.06, so this
was needed for an smooth upgrade.
IMHO it is safe to remove those lines, because this is only an issue in
oldstable. 

> > 
> > In Debian there is a file DwRandPrime.h which seems somehow
> > autogenerated. What is its purpose?
> 
> This is a weirdo. While building maradns generated a random prime
> number and writes it to DwRandPrime.h, I keep the upstream original in
> the debian repository to avoid "upstream changed" problems. After
> every build the DwRandPrime.h would be changed and gbp and debuild
> would complain. This assures reproductible builds.  
> > 
> > 

You can also just delete the file in the clean target ... Removed files
should not be a problem for dpkg-source. 
(However, it does not build then, so there is a problem with the build
system; The patch deadwood_makefile.patch applied is broken in this
aspect: It runs the Prime-Generator only if the file it should generate
is actually already there; see an attached a new version of this patch
which just moves the "fi" a little to the left.)

( There is also a similar hack with  rng/rng-32bit-tables.h in d/rules;
but I did not analyze what to do to remove this hack...)
version=3
opts=pgpsigurlmangle=s/$/.asc/ http://maradns.samiam.org/download.html .*/maradns-(\d[\d\.]+)\.tar\.(?:gz|bz2)$
Author: Nicholas Bamber <nicholas@periapt.co.uk>
Subject: deadwood source code corrupted during build
 Also we don't like binaries with a capital in the name.
Forwarded: not-needed
Last-Update: 2014-02-25
--- a/deadwood-3.2.05/src/Makefile
+++ b/deadwood-3.2.05/src/Makefile
@@ -20,7 +20,7 @@
 	DwRecurse.o \
 	DwDict.o
 
-all:	Deadwood version.h
+all:	deadwood version.h
 
 # Since some systems may not have /dev/urandom (Windows, *cough* *cough*), we 
 # keep a randomly generated prime around 
@@ -30,12 +30,8 @@
 
 clean:
 	rm -f Test DwMain DwTcp *.exe *.o a.out RandomPrime writehash_test* \
-		Deadwood foo* dw_cache DwHash DwCompress *stackdump \
-		core ; \
-		./make.version.h ; if [ -e /dev/urandom ] ; \
-			then rm DwRandPrime.h  ; \
-			cc RandomPrime.c ; ./a.out > DwRandPrime.h ; rm a.out \
-		; fi 
+		deadwood foo* dw_cache DwHash DwCompress *stackdump core
+		if [ -f DwRandPrime.h.bak ]; then mv DwRandPrime.h.bak DwRandPrime.h; fi
 
 version.h:	
 	./make.version.h
@@ -71,7 +67,7 @@
 	$(CC) -O3 -o RandomPrime RandomPrime.c
 
 DwRandPrime.h: RandomPrime
-	if [ -e /dev/urandom ] ; then ./RandomPrime > DwRandPrime.h ; fi
+	if [ -e /dev/urandom -a -f DwRandPrime.h ] ; then mv -f DwRandPrime.h DwRandPrime.h.bak ; fi ; ./RandomPrime > DwRandPrime.h
 
 DwHash.o:	DwHash.c DwStr.h DwRandPrime.h DwHash.h
 	$(CC) $(FLAGS) -Wall -c -o DwHash.o DwHash.c
@@ -85,6 +81,6 @@
 Test:		Test.c DwStr.o DwStr.h DwStr_functions.h $(OBJS)
 	$(CC) $(FLAGS) -Wall -o Test Test.c $(OBJS)
 
-Deadwood:	DwMain.c $(OBJS) DwStr_functions.h version.h
-	$(CC) $(FLAGS) -Wall -o Deadwood DwMain.c $(OBJS) -lrt
+deadwood:	DwMain.c $(OBJS) DwStr_functions.h version.h
+	$(CC) $(FLAGS) -Wall -o deadwood DwMain.c $(OBJS) -lrt
 

Reply to: