Re: Some upcoming dpkg changes, test and feedback welcome
On Wed, 20 Jul 2011, Guillem Jover wrote: > I'd prefer to have the makefiles under scripts/mk/ (for example), as > those are definitely dpkg-dev specific, while the tables (which can > stay where they are now) can be eventually used by the C code. Ok. > I don't quite like the all-vars.mk name, but right now I cannot come > up with something better. The rest look good, matching the tool name > w/o the dpkg- prefix. full.mk? complete.mk? common.mk? default.mk? dpkg-vars.mk? build-vars.mk? > It probable makes sense to namespace vendor_derives_from with dpkg_. Right. > I think it would be more useful to add support to retrieve specific > fields from dpkg-parsechangelog (for which we arelady have a wontfix This is #284664. I dropped the wontfix tag because I also agree that it would be useful. > bug), and given that those should not really be overridable and I > think uncommonly used, they don't seem to belong on the makefiles. I don't really see the logic behind that statement. > > I have also decided to not export the build flags in the environment by > > default. If the caller really wants this, he should set > > DPKG_EXPORT_BUILDFLAGS. > > Why? Because many people believe that the correct way to pass CFLAGS to the build system is on the ./configure command line and not through the environment. And debian/rules doesn't know all variables that buildflags.mk might set so it can't reliably call unexport on all variables. Instead it should use a flag that controls the behaviour of buildvars.mk. That said if you believe the correct default is to export the variables I'm happy to reverse the test and ask people who don't want it in the environment to set DPKG_DONT_EXPORT_BUILDFLAGS. I really don't have any personal preference here. > > As discussed on debian-devel at the end of may, I have implemented > > some changes to source format 3.0 (quilt) so that a build fails if there > > are upstream changes which are not yet managed by quilt. Recording the > > change in a new quilt patch must now be done explicitly by the maintainer > > with dpkg-source --record-changes. This will require the user to give > > a patch name and an editor will be run to let the maintainer edit the > > patch header. > > Did you consider naming it something like --commit instead? Nope, good idea. Shorter, maybe not clearer for everybody but definitely clearer for anyone with VCS experience. > > It required some important restructuring of the source package build > > procedure so I would be glad to have some more people running with this. > > Also you might have some input on the new interface. > > It would be preferable in general to split refactoring from new > additional features so that reviewing is actually easier. I know. For some reasons, I did not manage it this time. Every time I tried I got hit by further complications. And I also like to have each pushed commit as "working" at least in theory. I don't like to split commits if I know that it leaves flaws in some of the intermediary commits. > > 4/ We should really think of releasing 1.16.1 once those changes are > > merged. Guillem, do you have other things that you wanted to see merged > > for 1.16.1? > > Yes, there are some pending changes I want to merge first, some > requirements for the other multiarch changes, but I don't want to > upload it as long as at least the the Build-Features stuff is on > master. What about merging pu/build-arch and documenting the Build-Features: build-arch as only useful if the auto-detection doesn't work or has bad side effects? And explain that in any case, its usage should only last for as long as the auto-detection remains in place, that is until all Debian packages have been modified to provide the required targets. The rebuild stats shown on the tech-ctte bug proved that this is a sensible migration scenario. Cheers, -- Raphaël Hertzog ◈ Debian Developer Follow my Debian News ▶ http://RaphaelHertzog.com (English) ▶ http://RaphaelHertzog.fr (Français) -- To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110720123250.gd1...@rivendell.home.ouaza.com
Re: alternatives DB corruption
Hi Raphael Am Mi, 20.07.2011, 12:16 schrieb Raphael Hertzog: > please use the mailing list debian-dpkg@lists.debian.org next time. I've added a Cc: to the list. > On Wed, 20 Jul 2011, Michael Neuffer wrote: >> I have ad "db" file which seems to be corrupt and i can't figure out >> what is wrong. > > The database file is corrupted. What did you do to corrupt it? Is there a > reliable way to corrupt it? Yes, by editing it by hand. :-) I had to do it a few weeks earlier to remove some alternatives that were corrupted by a broken package. (Things that constantly using unstable can do to you...) I had to edit and fix alternatives manually every now and then over the past 15 years or so and never had (major) problems with that. Maybe I was just lucky so far. > It lacks lots of empty lines at the end. Each alternative should have a > set of line like this: > > > > > ... > > > Yet your last alternative only has 4 lines: > > /usr/lib/x86_64-linux-gnu/mesa/ld.so.conf > 500 > > /usr/lib/x86_64-linux-gnu/xorg/x11-extra-modules > Yes I removed them. I wasn't aware that they were significant. The file format unfortunately isn't documented in the man page. Is there a way to find out how many empty lines are missing where? Cheers Mike -- To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/710f483c8257d57dba121e528ccb4edb.squir...@www.neuffer.com
Re: alternatives DB corruption
On Wed, 20 Jul 2011, Michael Neuffer wrote: > > The database file is corrupted. What did you do to corrupt it? Is there a > > reliable way to corrupt it? > > Yes, by editing it by hand. :-) So there's no bug in update-alternatives at least. > I had to do it a few weeks earlier to remove > some alternatives that were corrupted by a broken package. > (Things that constantly using unstable can do to you...) Hum, that should not happen. You should always be able to update-alternatives to fix stuff. > I had to edit and fix alternatives manually every now and then over the > past 15 years or so and never had (major) problems with that. Maybe I was > just lucky so far. You won't have to do this in the future, update-alternatives no longer allows installation of broken alternatives and fixes stuff itself for most cases. > > It lacks lots of empty lines at the end. Each alternative should have a > > set of line like this: > > > > > > > > > > ... > > > > > > Yet your last alternative only has 4 lines: > > > > /usr/lib/x86_64-linux-gnu/mesa/ld.so.conf > > 500 > > > > /usr/lib/x86_64-linux-gnu/xorg/x11-extra-modules > > > > Yes I removed them. I wasn't aware that they were significant. *shrug* > The file format unfortunately isn't documented in the man page. Because it's not meant to be edited with anything else than update-alternatives... > Is there a way to find out how many empty lines are missing where? I documented the format above... in your specific case you need 15 lines in total (master + priority + 13 slaves). You already have 4 lines so you need 11 empty lines after. Cheers, -- Raphaël Hertzog ◈ Debian Developer Follow my Debian News ▶ http://RaphaelHertzog.com (English) ▶ http://RaphaelHertzog.fr (Français) -- To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110720124038.ge1...@rivendell.home.ouaza.com
Re: Some upcoming dpkg changes, test and feedback welcome
On Wed, 20 Jul 2011, Raphael Hertzog wrote: > > bug), and given that those should not really be overridable and I > > think uncommonly used, they don't seem to belong on the makefiles. > > I don't really see the logic behind that statement. Forgot to expand a bit: the version related variables are commonly used in "get-orig-source" targets, and it would be nice to factor out the version splitting logic. The source package name is often the same as the name of the only binary package and it's also relatively frequently used to avoid hardcoding debian/packagename/ everywhere in the rules files. Thus my personal preference would be to provide something to cover those use cases. I did put the distribution too because I have seen GNOME packages checking that the distribution was really experimental to avoid unexpected uploads to unstable. But this is really less frequent. Cheers, -- Raphaël Hertzog ◈ Debian Developer Follow my Debian News ▶ http://RaphaelHertzog.com (English) ▶ http://RaphaelHertzog.fr (Français) -- To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110720125128.gf1...@rivendell.home.ouaza.com
Re: alternatives DB corruption
On Wed, 20 Jul 2011, Michael Neuffer wrote:
> > Hum, that should not happen. You should always be able to
> > update-alternatives to fix stuff.
>
> Not when you manage to get into circular dependencies.
You will have to be more specific because this doesn't mean anything to
me.
> > You won't have to do this in the future, update-alternatives no longer
> > allows installation of broken alternatives and fixes stuff itself for most
> > cases.
>
> When did that change get rolled out?
With squeeze (dpkg >= 1.15).
> Manually fixing up dpkg status & info files becomes an ingrained habit
> over the years. The Debian & Ubuntu bleeding egde will cut you every now
> and then with problems that force manual intervention.
While this can be true for {post,pre}{inst,rm}, it's completely
wrong for most others status files (except maybe the statoverride one when
user/groups disappear).
Cheers,
--
Raphaël Hertzog ◈ Debian Developer
Follow my Debian News ▶ http://RaphaelHertzog.com (English)
▶ http://RaphaelHertzog.fr (Français)
--
To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110720150315.ga6...@rivendell.home.ouaza.com
Re: alternatives DB corruption
Am Mi, 20.07.2011, 14:40 schrieb Raphael Hertzog: > On Wed, 20 Jul 2011, Michael Neuffer wrote: >> > The database file is corrupted. What did you do to corrupt it? Is >> there a >> > reliable way to corrupt it? >> >> Yes, by editing it by hand. :-) > > So there's no bug in update-alternatives at least. No, not that I know of. >> I had to do it a few weeks earlier to remove >> some alternatives that were corrupted by a broken package. >> (Things that constantly using unstable can do to you...) > > Hum, that should not happen. You should always be able to > update-alternatives to fix stuff. Not when you manage to get into circular dependencies. >> I had to edit and fix alternatives manually every now and then over the >> past 15 years or so and never had (major) problems with that. Maybe I >> was >> just lucky so far. > > You won't have to do this in the future, update-alternatives no longer > allows installation of broken alternatives and fixes stuff itself for most > cases. When did that change get rolled out? >> > It lacks lots of empty lines at the end. Each alternative should have >> a >> > set of line like this: >> > [...] >> Yes I removed them. I wasn't aware that they were significant. > > *shrug* :-) >> The file format unfortunately isn't documented in the man page. > > Because it's not meant to be edited with anything else than > update-alternatives... Maybe a warning in the manpage would be good. Manually fixing up dpkg status & info files becomes an ingrained habit over the years. The Debian & Ubuntu bleeding egde will cut you every now and then with problems that force manual intervention. >> Is there a way to find out how many empty lines are missing where? > > I documented the format above... Yes thank you for that. > in your specific case you need 15 lines > in total (master + priority + 13 slaves). You already have 4 lines so you > need 11 empty lines after. Thanks! I'll give it a shot when I'm back home. Currently I don't have my laptop with me. Cheers Mike -- To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/fe5cbc05f677d24daa0ffbd19f1632a7.squir...@www.neuffer.com
