Bug#626775: lintian: should accept any all in Architecture in .dsc and not trigger magic-arch-in-arch-list
Raphaël Hertzog hert...@debian.org writes: Next version of dpkg (1.16.1) will keep all in the Architecture field on .dsc even if there's a binary with architecture any. But when a .dsc contains Architecture: any all, lintian complains with: E: dpkg source: magic-arch-in-arch-list N: N: The special architecture value any only make sense if it occurs N: alone. The value all may appear together with other architectures in N: a *.dsc file but must occur alone if used in a binary package. N: N: Refer to Debian Policy Manual section 5.6.8 (Architecture) for N: details. N: N: Severity: serious, Certainty: certain N: This error is correct for the fields in debian/control but not for the architecture field in the .dsc. Please update lintian (I'll file a bug against policy at the same time). Hi Raphaël, Policy 5.6.8 specifically says this is not allowed. So I think the cleaner sequence here would have been: 1. File a bug to request a change to Policy and get consensus on that change, waiting for that change to be approved. (You don't have to wait for it to actually get applied, certainly. That's sometimes slow. But at least raising it and getting some seconds.) 2. File a bug asking for Lintian to be updated to reflect the Policy change (or just wait for Policy to be released, since we update Lintian to match Policy). 3. Then change dpkg. You certainly have good reasons for these design choices, and I think it's unlikely anyone is going to object to this one in particular, but these interfaces are project-wide interfaces and sometimes changes cause unexpected problems. I'm probably just reading a bit too much finality into next version of dpkg (1.16.1) will keep, but it can be a bit off-putting to get the feeling that dpkg's source code is authoritative for the meaning of Policy-standardized fields and the rest of the project is expected to get in line without any other discussion. I think it creates some unnecessary tension that the above order would have defused. All that said, this seems like a reasonable change to me, and I'll happily second the Policy bug. (I suspect that this ordering may be due to slowness in action on Policy bugs, which I know has been a source of frustration for some of your work. If you have a moment to come up with a list of Policy bugs that you find particularly vexing and would like to get resolved, particularly if any of them are relatively straightforward, could you send me that list? I have more time right now to work on Policy than I have in quite a while, and I promise to take a look. dpkg-buildflags is already high on my list, for example.) -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-lint-maint-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87ei40l5lt@windlord.stanford.edu
Please i wait to hear from you, its very important
I am Ian Davies ;an accredited vendor of Alliot Groups, a subsidiary firm of Emirates International Holding (EIH); A private equity funds holding company that focuses on hedge funds. I have contacted you in the hope that you can be my associate by accepting to stand as the legal recipient to a Fixed-Income deposit, valued at 25MUSD by providing an International Offshore account to clear the funds. Once I file your details as the new recipient to the funds, the funds will be approved through the AUTOMATED CLEARING HOUSE (ACH) - A facility used by financial institutions to distribute electronic debit and credit entries to bank accounts and therefore settles such entries. Under the automated clearing house system. upon approval of your details as the new recipient; a Credit advice will be issued in your favor and the funds will clear in your account within three banking days. I am willing to give you 40% which is 10MUSD as your commission out of the 25MUSD for your assistance in providing an International Offshore account to clear the funds. I am confident you will be honest enough to adhere to our agreed commissions in spite of the 25MUSD coming through your account. I will need you to forward me your legal names address and phone to file your details on the fund as the new recipient in this first Quarter of the financial fiscal year 2011. Looking forward to working with you. Ian Davies Accredited vendor Alliot Groups PS -- To UNSUBSCRIBE, email to debian-lint-maint-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110513200052.056231b7...@fire3.aciu.com.br
Bug#626775: lintian: should accept any all in Architecture in .dsc and not trigger magic-arch-in-arch-list
Hi, On Sun, 15 May 2011, Russ Allbery wrote: I'm probably just reading a bit too much finality into next version of dpkg (1.16.1) will keep, but it can be a bit off-putting to get the feeling that dpkg's source code is authoritative for the meaning of Policy-standardized fields and the rest of the project is expected to get in line without any other discussion. I think it creates some unnecessary tension that the above order would have defused. Well, it was not meant to override the normal process, but I expected it would not create problems so I did it all at once. But you're entirely entitled to mark the lintian bug as blocked by the policy one (that's why I mentioned that I was filing a policy one in parallel). (I suspect that this ordering may be due to slowness in action on Policy bugs, which I know has been a source of frustration for some of your work. If you have a moment to come up with a list of Policy bugs that you find particularly vexing and would like to get resolved, particularly if any of them are relatively straightforward, could you send me that list? I have more time right now to work on Policy than I have in quite a while, and I promise to take a look. dpkg-buildflags is already high on my list, for example.) Oh no, I'm not frustrated at all. On the contrary, I know that a bug with a good rationale and a good patch can be quickly seconded and merged, and thus it was more efficient to do everything at once. Cheers, -- Raphaël Hertzog ◈ Debian Developer Follow my Debian News ▶ http://RaphaelHertzog.com (English) ▶ http://RaphaelHertzog.fr (Français) -- To UNSUBSCRIBE, email to debian-lint-maint-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110515193648.ga32...@rivendell.home.ouaza.com
