People these days often do think about what worked well in the last year that they are proud of, what didn't work so well and what they plan to change the coming year. For me a fair amount of the resolutions were about my name. One of them was getting rid of my old name from the Debian—Project Participants page. Actually, I started with it on new year's eve already:
So far I've done a fair amount of my job. There are eight source package left to get tweaked. Those might be a bit more difficult and require more attention though. What I also did during those efforts: Convert all packages to source format 3.0 (quilt), and use a dh style debian/rules file. The latter enabled the packages to build reproducible too, which is also an added benefit. So this is a win situation on many levels.
One of the most prominent reasons why I didn't convert to a dh style debian/rules file yet was that I considered it making easy things easy and difficult things difficult. Finding out what to override and how to do that was something I was unable to figure out, and speaking with people didn't help me there neither. Only recently someone told me that there is dh binary --no-act to figure out what would be called, and then you just prefix it with override_ in debian/rules to get to where you want to go. This worked extremely well for me.
I'm personally still not a big fan of source format 3.0 (quilt) with respect to that it insists on patches to be applied and leaves them that way after building the source package, which makes it difficult to deal with when having upstream source in the VCS too, but I managed to find my way around so many things in the past that I can live with that. The benefit of not having to repack upstream source if it isn't in .gz form is a far bigger benefit.
So, I hope to stay productive and be able to get the remaining package also adjusted and fixed. Guess that's doable until the end of the month, and getting rid of all reproducible build bugreports against my packages along that lines. I will check those packages that carry my name already too after my old name is gone from the overview page.
> format 3.0 (quilt) insists on patches to be applied and leaves them that way after building the source package
This is not correct. dpkg-buildpackage does unapply patches if they were not applied when the build started. And it has been that way for a long time now...
Rhonda wrote at 2016-01-13 10:59:
> dpkg-buildpackage does unapply patches if they were not applied when
> the build started.
That might well be it, but dpkg-source doesn't do anything along the lines. It applies the patches for building the source package, but never unapplies them which is what I'm referring to. I don't have the Build-Dependencies installed on the system where I work on the source and prepare the source package to hand over to my build instance.
Raphaël Hertzog wrote at 2016-01-13 11:12:
OK. You might want to use "dpkg-buildpackage -S -d" then. And possibly file a wishlist bug to see if dpkg-source can be improved in a similar way...
Rhonda wrote at 2016-01-13 11:28:
"dpkg-buildpackage -S -d" isn't enough. The "-nc" switch is needed too, otherwise the clean target is called and the Build-Depends are required to be around too. Thanks to Myon for pointing that out.
rbalint wrote at 2016-01-13 14:20:
Thanks for the hint on "dh binary --no-act" :-)
Comments are closed for this story.
Feeds
If you want to
syndicate this blog,
feel free to do so.
This list contains the feeds that I follow:
![[rss feed]](/pics/logo-xml.png){kind=logo}
![[html by vim]](/pics/logo-vim.png){kind=logo}
![[graphics by gimp]](/pics/logo-gimp.png){kind=logo}
![[generated by wml]](/pics/logo-wml.png){kind=logo}
![[powered by blosxom]](/pics/logo-blosxom.png){kind=logo}
Raphaël Hertzog wrote at 2016-01-13 10:24:
Rhonda wrote at 2016-01-13 10:59:
Raphaël Hertzog wrote at 2016-01-13 11:12:
Rhonda wrote at 2016-01-13 11:28:
rbalint wrote at 2016-01-13 14:20:
Comments are closed for this story.