Re: Strange armel build error
On Sun, 2024-08-18 at 14:23 +0500, Andrey Rakhmatullin wrote: > On Sun, Aug 18, 2024 at 11:02:03AM +0200, Alec Leamas wrote: > > Hi Stephen, > > > > On 18/08/2024 09:04, Stephen Kitt wrote: > > [...] > > > If you can’t fix the build, you don’t need to exclude the > > > architecture — you > > > can ask for removal of the armel package in testing. That will > > > allow the > > > package to migrate even if armel is missing. > > > > > This looks to me like a sound solution in this case. After all, > > opencpn is a > > full-fledged GUI leaf package without reverse deps and zero users > > on armel > > hardware. But then again, how is this done? > > If by this you mean asking for a removal then reportbug > release.debian.org Not for an architecture-specific removal. Those happen in unstable and then propagate to testing, so it's ftp.debian.org. Regards, Adam
Re: Ignoring the truth or Hiding problems? (was: Are mails sent to xxxx buildd.debian.org sent to /dev/null ?)
On Wednesday, January 05, 2005 8:42 AM, Ingo Juergensmann <[EMAIL PROTECTED]> wrote: > Regarding James Troup... [...] > I still believe that it would be better for the project when he would retire from > some of his many positions, because he's too loaded with them. I'm assuming you haven't spotted the recent announcement that he now has assistance with much of the day-to-day work of one of those positions? (iirc, the one you're most fond of complaining about). [fwiw, if I understand correctly, the person in question was appointed after having spent considerable time contributing to the NM process and asking "can I help lighten your workload?", as opposed to "I don't think you're doing a good enough job, let me do it"]. Cheers, Adam
Re: Ignoring the truth or Hiding problems? (was: Are mails sent to xxxx buildd.debian.org sent to /dev/null ?)
On Wednesday, January 05, 2005 10:05 AM, Ingo Juergensmann <[EMAIL PROTECTED]> wrote: [...] > When Joerg Jaspert is already doing the dirty daily work, why does > James still needs in place then? (Except he just stays in that > position for a transitional period until Joerg is taking over that > task and job completely. I would recommend that transitional period > for other positions as well.) aiui, because James - or presumably some other member of -admin - needs to create the accounts once an nm has been approved (newsamosa, aka db.d.o is restricted). The most time-consuming part of DAM work is approving applicatants, which is what Joerg is now doing. afaics, once an applicant is approved, accounts are being created relatively quickly; so far it appears to be working well. Cheers, Adam
Re: removal syncing among "official" and amd64 archive
On Sat, 2005-11-19 at 18:42 +0100, Goswin von Brederlow wrote: > Stefano Zacchiroli <[EMAIL PROTECTED]> writes: > > > While we are it ... I noticed that removal of packages from the official > > debian archive are not propagated to the amd64 archive. E.g. query > > packages.debian.org for the "editex" source package. > > > > Is that known? > > No. removals should propagate to amd64 with some delay. How long ago > was it removed? A few months ago. = [Date: Thu, 28 Jul 2005 11:26:16 -0700] [ftpmaster: Jeroen van Wolffelaar] Removed the following packages from unstable: editex |0.0.5-6 | source libeditex-dev |0.0.5-6 | alpha, arm, hppa, i386, ia64, m68k, mips, mipsel, powerpc, s390, sparc libeditex-ocaml |0.0.5-6 | alpha, arm, hppa, i386, ia64, m68k, mips, mipsel, powerpc, s390, sparc libeditex-ocaml-dev |0.0.5-6 | alpha, arm, hppa, i386, ia64, m68k, mips, mipsel, powerpc, s390, sparc libeditex0 |0.0.5-6 | alpha, arm, hppa, i386, ia64, m68k, mips, mipsel, powerpc, s390, sparc Closed bugs: 317298 --- Reason --- RoM; unsupported upstream, buggy -- = Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: dpkg-sig support wanted?
On Thursday, November 24, 2005 11:17 AM, Wouter Verhelst <[EMAIL PROTECTED]> wrote: > On Thu, Nov 24, 2005 at 02:11:45PM +1100, Matthew Palmer wrote: [...] >> On that score, the description for d-d-c says that it includes >> buildd logs, > > Then that description is wrong. It never did include buildd logs, and > AFAIK, there are no plans to that effect, either. It doesn't say that. It says: "Notices about uploaded packages for the unstable distribution, from developers, buildds and katie, the archive sentinel." i.e. the only e-mails from buildds involved are "notices about uploaded packages", not logs. Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: packages.debian.org service stop ?
On Thursday, January 12, 2006 11:59 PM, Junichi Uekawa <[EMAIL PROTECTED]> wrote: > Hi, > > I've dug out some information from IRC logs: > > saens was overloaded around 5 Jan 2006, with load average of 140 or > something, and eventually apache stopped. Since saens is one of > ftp.debian.org, it had a large impact, and packages.debian.org is > disabled temporarily as a workaround. FWIW, the same information is detailed in http://lists.debian.org/debian-project/2006/01/msg00035.html. Cheers, Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Obsolete packages in Experimental
On Thursday, January 19, 2006 11:35 AM, Jérôme Warnier <[EMAIL PROTECTED]> wrote: > After the last update of OOo in Sid (aka Unstable), I wonder if it is > generally considered acceptable to keep obsolete packages in > experimental (currently, Sid has 2.0.1-2 and Experimental 2.0.1-1). Further to other answers, in this particular case you were about six and a half hours out of date ;-) = [Date: Wed, 18 Jan 2006 21:06:31 -0800] [ftpmaster: Ryan Murray] Removed the following packages from experimental: [...] openoffice.org |2.0.1-1 | source, i386, powerpc, sparc openoffice.org-base |2.0.1-1 | i386, powerpc, sparc [...] openoffice.org-writer |2.0.1-1 | i386, powerpc, sparc [...] --- Reason --- [rene] NVIU -- = (i.e. rene, the archive "cruft remover" flagged the experimental packages for removal as there was a newer version in unstable). Cheers, Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: missing packages
On Wednesday, March 08, 2006 7:53 AM, Wolfgang Lonien <[EMAIL PROTECTED]> wrote: > I did an 'apt-cache stats' today, and it was very nice to see that we > have 17519 packages total. > > 3635 packages are "missing", however. An 'apt-cache unmet | grep -c > "unmet dep:" brings out 662 packages with unmet dependencies; > 'apt-cache -i unmet | grep -c "unmet dep:" shows 219 of them as > "important". My results (i386) are different from yours, but within the same order of magnitude. fwiw, only about half of that 600-odd are strictly dependencies; the other half are Suggests or Recommends. > Hmmm. That looks like a lot of work. But where to start? And who does > that? The QA team? http://qa.debian.org/debcheck.php Regards, Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: shell script sniplets in /usr/bin?
On Sun, 2005-01-30 at 17:18 +0100, Goswin von Brederlow wrote:
> Matthew Palmer <[EMAIL PROTECTED]> writes:
[...]
> > "Because I don't wanna play by the rules!" is not a rationale. So you have
> > to specify a path -- so what? The way things stand at the moment, if I were
> > to drop a gettext.sh in my ~/bin (which is quite likely, except that I don't
> > like to put a .sh on my helper scripts) your shell scripts would suddenly go
> > tits-up in a most unpleasant fashion. Personally, *that* would be enough to
> > make me want to hardcode the path.
[...]
> That is why you normaly have ~/bin last in PATH.
Not if you're using Debian's default install of bash you don't
(admittedly they're commented out by default, but...):
# set PATH so it includes user's private bin if it exists
if [ -d ~/bin ] ; then
PATH=~/bin:"${PATH}"
fi
More to the point, putting ~/bin last in PATH breaks most of the reasons
for having it there in the first place (being able to override
system-installed versions).
Adam
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: problems with public keys
"Nico Golde" <[EMAIL PROTECTED]> wrote, Wednesday, June 08, 2005 9:52 AM > My qa page http://qa.debian.org/[EMAIL PROTECTED] > looks like this: > General information for Id: [EMAIL PROTECTED] (click to > collapse) > GPG key id not found! (key id was not found neither in the > Debian keyring nor on a public keyserver) developer.php is currently configured not to check against any external keyservers. See #307461 and http://lists.debian.org/debian-qa/2005/05/msg2.html Regards, Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Questions on how to handle this: [EMAIL PROTECTED]: httperf_0.8-3_i386.changes REJECTED]
"Roberto C. Sanchez" <[EMAIL PROTECTED]>, wrote, on Friday, June 17, 2005 6:37 AM: > Below I have included the text rejecting my httperf package. I am > taking over as maintainer and uploaded a new version that also >closed a couple of bugs and moved it from non-US to main. If linking > with libssl is not permissible, should the version that is currently in > Sarge be slated for removal when 3.1r1 comes out? There is no httperf package in sarge, as there is no non-US archive for sarge, so the question is academic. As http://packages.debian.org/httperf shows, the package currently only exists in oldstable/non-US. Regards, Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Getting rid of circular dependencies, stage 5
On Thu, 2006-07-27 at 18:28 +0200, Goswin von Brederlow wrote: [breaking circular dependencies] > Dpkg does it the way policy says it should do it and even slightly > better since it checks for postinst files. That's unsurprising, given that the relevant sections of policy and dpkg were written by the same person. Specifically, the policy section was written as documentation of what dpkg /does/, rather than vice versa. Cheers, Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: huge wnpp bug report page
Hi, > I tried to take a look at the wnpp bug page but neither Konqueror > nor Firefox were able to handle it on my system. Really? Galeon handles it fine, as does Firefox (the latter on win32). > 3182462 bytes for the HTML code of a single web page is a bit much, isn't it? Possibly. It's also 25% greater than the size of the page you quoted (wgetting the page gives an output of 2634857 bytes). > Additionally, all links contain the server name. Why? Using > > would be enough and would save a lot regarding download size. All > the "http://bugs.debian.org/cgi-bin/"; prefixes could be ommitted. > This would reduce page size by 93 bytes per bug (> 500KB total). Erm... no, they don't. For instance, having a copy of ftp.d.o's bug page handy :) : #271782: udeb sources need to be in sarge Package: ftp.debian.org; Severity: important; Reported by: Goswin von Brederlow <[EMAIL PROTECTED]>; Tags: sarge; 1 year and 323 days old. Cheers, Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: dresden-ocl missing orig.tar.gz
Hi, On Wed, 2006-08-09 at 14:50 -0300, Felipe Augusto van de Wiel (faw) wrote: > I'm not quite sure how to report this. A user noted that > whatever mirror he used to create his own mirror (using debmirror) > he got a problem with dresden-ocl-1.0.1_orig.tar.gz. If he uses > - --nosources then he can get the mirror. [...] > And the .orig is not around. Not quite sure how to report > this, and I would be happy to know for future references. ;) This is an instance of a known issue that occurs when packages move between components - in this case, from contrib to main (bug #341858 against ftp.debian.org). Specifically, the uploaded source package (.dsc, .debs and .diff.gz) are correctly placed in pool/main. The .orig.tar.gz is already in the archive in its original location in pool/contrib. There are two means of resolving the issue - convince an ftpmaster to fiddle the archive database or upload a new upstream version, and therefore a new .orig.tar.gz. The latter is far easier, particularly if there's a new upstream to upload anyway. In this specific instance, the issue has already been reported, as #367267 (also against ftp.d.o). Cheers, Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#391171: ITP: grepcidr -- Filter IP addresses matching IPv4 CIDR/network
On Thursday, October 05, 2006 9:06 AM, Ryan Finnie <[EMAIL PROTECTED]> wrote: > Package: wnpp > Severity: wishlist > Owner: Ryan Finnie <[EMAIL PROTECTED]> > > > * Package name: grepcidr Erm... didn't you already submit this as #391168? :) Regards, Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: xv and xorg
Jiri Klouda wrote, Thursday, October 05, 2006 6:57 AM [...] > I just wanted to ask when xv is going to be updated or what is > holding it up or if someone has some suggestion how I could > upgrade and still get it working (some experimental xv package?) > or do I need to compile from sources? xv was removed from Debian over five years ago due to licensing issues, so I'm afraid you're likely to have to rebuild it yourself against xorg in order to make it work. [Date: Mon, 21 May 2001 17:39:32 -0400] [ftpmaster: James Troup] Removed the following packages from unstable: xv | 3.10a-24 | powerpc xv | 3.10a-25 | arm, m68k xv | 3.10a-26 | source, alpha, i386, sparc xv-doc | 3.10a-26 | all Closed bugs: 98215 --- Reason --- ROM; no permission to modify and redistribute. -- Regards, Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#391359: general: packages.debian.org package view could have a link to see the source changelog.
reassign 391359 qa.debian.org thanks On Friday, October 06, 2006 9:51 AM, Raúl Sánchez Siles <[EMAIL PROTECTED]> wrote: > Package: general > Severity: wishlist > > With aptitude changelog is quite easy to know the latest modifications > of a package, but it quite often refers to new upstream release. [...] > I wish I could see the source changelog from the packages.debian.org > package page. s/source/upstream/. packages.debian.org bugs don't belong to "general". Reassigning. Regards, Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: ftp upload queue?
On Monday, October 09, 2006 6:42 AM, Thomas Bushnell BSG <[EMAIL PROTECTED]> wrote: > Aurélien GÉRÔME <[EMAIL PROTECTED]> writes: > >> As soon as I send a mail, the deamon restarts... Good news! ;) > > Yep. Thanks magic elves! I've never really pictured aj as an elf... ;-) Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Why weren't the GR voting mails sent to debian-devel-announce?
On Mon, 2006-10-09 at 12:56 -0600, Oleksandr Moskalenko wrote: > According to the chapter 3.3 of the Dev. reference the GR calls for votes > should've been sent to the debian-devel-announce, but in reality they weren't. > It seems that the only way to get those would be to subscribe to debian-vote > or to trawl the debian-vote archives. Why is it so? They *were* sent to d-d-a. Each mail has To: debian-devel-announce@lists.debian.org, debian-vote@lists.debian.org and is archived at http://lists.debian.org/debian-devel-announce/2006/10/ (or /09/ for the earlier GRs). The headers of my copies of each mail also confirm they were sent to a tagged address subscribed only to d-d-a. Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug mass filling
On Thu, 2006-10-19 at 19:51 +0200, Mike Hommey wrote: > On Thu, Oct 19, 2006 at 07:36:27PM +0200, Andreas Barth <[EMAIL PROTECTED]> > wrote: > > > Doesn't policy violation warrant Critical severity? > > > > No. Please see the top of http://release.debian.org/etch_rc_policy.txt > > for which bugs are critical, grave and serious. > > That is irrelevant for the severity of bugs. [...] > Don't change severities for releasing-in-time purposes. There is Erm... the release team have been the arbiters of what merits an RC severity since at least before Sarge was released. >From http://www.debian.org/Bugs/Developer#severities: "Certain severities are considered release-critical, meaning the bug will have an impact on releasing the package with the stable release of Debian. Currently, these are critical, grave and serious. For complete and canonical rules on what issues merit these severities, see the list of Release-Critical Issues for Etch." The top of the latter page reads "The purpose of this document is to be a correct, complete and canonical list of issues that merit a "serious" bug under the clause "a severe violation of Debian policy". In addition to the issues listed in this document, an issue is release critical if it: [...] * in the maintainer's opinion, makes the package unsuitable for release (these issues are "serious" severity) " i.e. if it's not in the policy and doesn't meet the above definition, it's *not* severity serious or higher. I'd suggest reading http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=277074;msg=72, in which a current member of [EMAIL PROTECTED] (and at the time an RM) confirms that a member of the ftp-master team was correct in stating the above. Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug mass filling
On Thu, 2006-10-19 at 10:00 -0700, Kevin B. McCarty wrote: > Tshepang Lekhonkhobe wrote: > > > Doesn't policy violation warrant Critical severity? > > No, it "only" warrants the lowest RC severity, serious [0], unless the > bug in addition makes the package or other software (mostly) unusable, > causes data loss, or introduces a security hole. Even then, it's only "serious" if it violates the release policy [http://release.debian.org/etch_rc_policy.txt]. Hence the reason that > [0] http://www.debian.org/Bugs/Developer#severities says "[...]roughly, it violates a "must" or "required" directive". The final word for what justifies a release-critical severity belongs to the release team (hence also the paragraph on rc-ness at the foot of the documentation). Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Mass bug filing: failure to use invoke-rc.d when required
On Wednesday, May 17, 2006 7:59 AM, Lionel Elie Mamane <[EMAIL PROTECTED]> wrote: > On Wed, May 17, 2006 at 12:53:39AM +0300, Lars Wirzenius wrote: >> ti, 2006-05-16 kello 09:53 +0200, Bas Zoetekouw kirjoitti: [...] >>> AFAIK, vilolating policy always waarent a serious bug: [...] >> This is not what Steve Langasek tells me (or else I'm seriously >> misunderstanding). The etch_rc_policy.txt document is what documents >> what is release critical. > > Doesn't that mean the bug is severity serious, but should be tagged > "etch-ignore"? That's what we did with sarge, if I remember well? No. The "foo-ignore" tags mean "this issue /is/ RC, but we're ignoring it for the release of foo". Any bug tagged "etch-ignore" is by definition RC the moment etch is released. The exact definition of what qualifies for a severity of serious or above (i.e. RC) are the purview of the Release team, as noted at http://www.debian.org/Bugs/Developer#severities. A "severe violation of Debian policy" is one which violates the current release policy, as laid out by the Release team. Cheers, Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: net-tools maintenance status
On Friday, August 05, 2005 3:42 PM, Olaf van der Spek <[EMAIL PROTECTED]> wrote: > On 8/2/05, Bernd Eckenfels <[EMAIL PROTECTED]> wrote: >> On Tue, Aug 02, 2005 at 07:45:12PM +0200, Olaf van der Spek wrote: >>> What's the maintenance status of the net-tools package? >> >> It is maintained. Patches are welcome. >> >> http://packages.qa.debian.org/n/net-tools.html >> >> Which patch are you talking about? > > The one for --wide > Did you find it already? Any particular reason you didn't mail it to #222324? (I'm assuming that's the bug you're referring to; it's the only open bug against net-tools that mentions --wide, and neither of the bugs you've reported contain a patch) Regards, Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: http://www.debian.org/security/
On Tuesday, September 13, 2005 9:08 AM, Aaron Fisher <[EMAIL PROTECTED]> wrote: > I am having the same problem with a sources.list file that reads as > follows [...] > deb http://security.debian.org stable updates [...] > Err http://security.debian.org stable/updates Packages > > 404 Not Found That's hardly surprising, given that the path you've supplied doesn't - and isn't expected to - exist. As http://www.debian.org/security/ says, it should be: deb http://security.debian.org/ sarge/updates main contrib non-free (obviously contrib and non-free are optional, but (sarge|stable)/updates is one stanza not two and you need at least one of (main|contrib|non-free)). Cheers, Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: better init.d/* : who carres ?
On Wed, 2005-09-28 at 23:56 +0300, Jari Aalto wrote: > Alfie Costa <[EMAIL PROTECTED]> writes: > > | Wed, 21 Sep 2005 09:32:41 +, Gerrit Pape wrote: > | > | ...but try come up with a rule of thumb for '%%' (big suffix), '#' > | (small prefix), etc.? Maybe the 'p' in percent is for Prefix -- but no, > | the Prefix is the hash symbol; two signs are bigger than one, like Roman > | numerals... it's a puzzle. > > It's in fact easier; the keys can be visualized easily. On keyboard: > > # % > > is on the leftis on the right Not on an en_GB keyboard they aren't. (Leaving aside the fact that at least en_GB iMac keyboards don't even have a key with a # legend). Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Testing-watch emails
On Sat, 2005-11-05 at 00:17 +0100, Henning Makholm wrote:
> Scripsit Steve Langasek <[EMAIL PROTECTED]>
>
> > If you're interested in making this happen I'll be happy to give
> > you any info I can;
>
> OK, here are some questions.
>
> 1) The copy of britney in merkel:/org/ftp.debian.org/ does not seem
> to be synced regularly. Is there a place where one can see the
> current code? It's not in the dak cvs (which appears to be
> out-of-date wrt the merkel mirror anyway), and I tried poking
> around on {cvs,svn,arch}.debian.org to no avail.
http://ftp-master.debian.org/testing/update_out_code/ is the "official"
current code, afaik. From time to time, there may be other versions
floating around - there's a least one in ~ajt on ftp-master currently.
> 3) Do you (or somebody in QA who reads this) happen to know how the
> 'keyword' under which the PTS forwards emails is transmitted? I
> cannot find any code in katie that sets this. Does the PTS analyse
> subject lines for fixed patterns?
[EMAIL PROTECTED] is subscribed to -devel-changes and processes
the mails in real-time.
http://cvs.debian.org/pts/?cvsroot=qa is useful here.
http://wiki.debian.org/qa.debian.org/pts is linked from the front page
of p.qa.d.o, and contains a link to a presentation Raphael Hertzog
(buxy) made about the PTS.
> (Currently I'm extrapolating from the documented
> [EMAIL PROTECTED] syntax, but I'm not sure
> that is the Right Thing to do).
>
> I'm not sure this is the right list to ask on, what with this being
> technical matters rather than a flamewar. :-) Feel free to move to
> somewhere appropriate, cc'ing me.
In terms of the PTS, either asking buxy directly or [EMAIL PROTECTED] usually
works. britney and other ftp-master related topics are probably most
appropriate on [EMAIL PROTECTED], imho.
Adam
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: late at night... can't think -- why is my bugs are not closed?
Hi, Yaroslav Halchenko wrote, Wednesday, January 23, 2008 8:03 AM In a fresh package (edac-utils) I have closed a bug in recent upload (proper Closes statement and a Closes in .changes). But bug remains Done but not closed: #456644. From edac-utils' bug index: Debian Bug report logs: Bugs in package edac-utils (versions 0.10-2 [alpha, amd64, arm, i386, ia64, mips, powerpc, s390, sparc], 0.10-1 [m68k]) in unstable [...] #456644: edac-utils: Errors were encountered during configuration Package: edac-utils (edac-utils 0.10-1; fixed: edac-utils 0.10-2); i.e. the m68k package in unstable is still buggy. The bug will stop being "outstanding" once it isn't present in any package - i.e. once m68k has -2 in the archive. Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: late at night... can't think -- why is my bugs are not closed?
Hi, On Wed, 2008-01-23 at 22:39 -0500, Yaroslav Halchenko wrote: > Well... as Neil pointed it seems not to be the case -- m68k arch is > still -1 but now it is "resolved". Where are you seeing it as "resolved"? It's still listed as outstanding on http://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=edac-utils;dist=unstable Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: checkbashisms: fails to detect shell wrappers
On Wed, 2008-01-30 at 13:40 -0600, Raphael Geissert wrote: > Russ Allbery wrote: > > > Raphael Geissert <[EMAIL PROTECTED]> writes: > > > >> This sounds more like a report against checkbashisms. > >> I guess it could try to detect these: > > > > See script_is_evil_and_wrong() in lintian's check/scripts. > > > > Based on the next statement on checkbashisms I though they were kept in > sync: > > > # This script is essentially copied > from /usr/share/lintian/checks/scripts, It should probably say "was", rather than "is". That said, I'll have a look at updating checkbashisms's parsing code in line with lintian's (probably over the weekend). Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: List of packages shipping shell scripts with bashisms + MBF proposal
On Wed, 2008-01-30 at 10:29 -0800, Russ Allbery wrote: > Raphael Geissert <[EMAIL PROTECTED]> writes: [...] > > The script basically uses find on those directories (under /usr/share it > > only searches for '*.sh') and then uses file on those to get a new list > > of those file being shell scripts which are then checked with > > checkbashisms. > > lintian shouldn't depend on checkbashisms. It already has its own > implementation of this code (which from this thread is actually better). lintian's parsing code certainly sounds better (mainly because checkbashisms is based on an old version of the lintian code) but, from a quick look, checkbashisms flags more issues than lintian does. We do appear to be missing a few though; I'll have a look at getting them back in sync. Adam (with devscripts hat on) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: List of packages shipping shell scripts with bashisms + MBF proposal
On Sat, 2008-02-09 at 16:39 -0800, Russ Allbery wrote: > Raphael Geissert <[EMAIL PROTECTED]> writes: > > > Atm, checkbashisms only complains with this: > > > >> _From_: bashisms-amd64-2.10.15/libtool_1.5.26-1_amd64.deb > >> possible bashism in ./usr/bin/libtool line 1218 (trap with signal > > numbers): > >> trap "$run $rm $removelist; exit $EXIT_FAILURE" 1 2 15 > > This one is somewhat arguable. Pure POSIX doesn't allow signal numbers, > but the XSI extension to POSIX does and dash and posh both support them. > We do not, in general, accept XSI extensions, but it's hard to argue > strongly for excluding a feature that even posh supports. That check was recently added during the lintian <-> checkbashisms sync. If the feeling is that its incorrect, it should probably be removed from lintian as well. Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: List of packages shipping shell scripts with bashisms + MBF proposal
On Sat, 2008-02-09 at 16:59 -0800, Ben Pfaff wrote: > Raphael Geissert <[EMAIL PROTECTED]> writes: > > > Atm, checkbashisms only complains with this: > > > >> _From_: bashisms-amd64-2.10.15/libtool_1.5.26-1_amd64.deb > >> possible bashism in ./usr/bin/libtool line 1218 (trap with signal > > numbers): > > It's weird that it calls this a "possible bashism". It's not a > bashism (at most, it's an XSI-ism) and it's so pervasively > supported that even Autoconf uses it. In hindsight, checkbashisms may not have been the best name for the script, but checkscriptcompliestosus isn't quite as catchy. :-) I'm debating adding an option to ignore XSI-isms when checking scripts. However, I will add that a) the check is also in lintian, albeit only for maintainer scripts and b) so far as I can see, using it in scripts with a /bin/sh shebang is technically a policy violation, even if not one that people care about. Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Version numbering for security uploads of native packages
[nutshell version for those who can't be bothered to read the full mail :-) - what version number should a security upload of a native package have] Hi, devscripts 2.10.19 (soon to be uploaded) will modify the behaviour of "debchange --nmu" to version an NMU of a native package as X+nmu1 rather than the current X-0.1. We're aware that the Developers Reference specifies that the latter format should be used, but it is problematic as -0.1 sorts before +b1 and, as such, the NMU will not supersede any previous binNMUs of the same package version. Whilst looking at this change, the question arose of what format security uploads of native packages should use, both in general and specifically when debchange's --security option is used. Currently, debchange will produce a version number of X-0.1 in such cases which suffers from the problem described above. It has been suggested that either one of +s1 / +sec1 / +security1 or 1 should be used to avoid the issue. The main difficulty with the latter from the point-of-view of adding support to debchange is that there's no easy way of mapping a changelog distribution (e.g. "stable") to a release name, particularly as both stable and oldstable updates may have "stable" as the last distribution to which the package was uploaded. After some discussion amongst the team on IRC we decided we'd be happiest following either a request from the security team or a consensus view (or as close to a consensus as -devel ever gets :-). Cheers, Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Version numbering for security uploads of native packages
On Sun, 2008-03-16 at 03:47 -0700, Steve Langasek wrote: > The current binNMU numbering scheme was selected explicitly to allow > security uploads to sort later by numbering as > +; e.g., 1.2-5.1+etch1. That makes sense, although doesn't seem to match current practice. Was any consideration given as to where NMUs of native packages should sort? (I realise that they're the only case that doesn't automagically dtrt with respect to the numbering scheme). Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Version numbering for security uploads of native packages
On Sun, 2008-03-16 at 09:06 +0100, Bas Wijnen wrote: > [Adding bug #437392 to Cc, which deals with this issue for normal > NMUs, because I'm making a suggestion about them.] > > On Sat, Mar 15, 2008 at 11:52:55PM +, Adam D. Barratt wrote: > > devscripts 2.10.19 (soon to be uploaded) will modify the behaviour > of > > "debchange --nmu" to version an NMU of a native package as X+nmu1 > rather > > than the current X-0.1. > > Good idea. Even better, IMO, would be to use a system which is in > line with non-native packages. How about this rule: [using X.1] > IMO this solution is slightly better than +nmu1, because it makes > versions of native and non-native packages more uniformly mangled. > However, any solution is better than no solution. :-) That does seem the most logical suggestion thus far. As .19 fixes a couple of regressions I'd like to get it uploaded soon so may stick with +nmu for the moment (as you say, it's still better than -0.1). [...] > > It has been > > suggested that either one of +s1 / +sec1 / +security1 or 1 > > should be used to avoid the issue. > > > > The main difficulty with the latter from the point-of-view of adding > > support to debchange is that there's no easy way of mapping a changelog > > distribution (e.g. "stable") to a release name, particularly as both > > stable and oldstable updates may have "stable" as the last distribution > > to which the package was uploaded. > > So the problem is that debchange is unable to know the version should be > "stable"? Or is the problem that versions may collide when oldstable > has a security update, and stable needs one as well? The problem is that the security team want to use version numbers such as "Xetch1" or "Xsarge1" and these can't reliably be deduced simply by looking at the package. If one takes the case of a package in etch or sarge that has not yet had a security update, how would dch know whether to use sarge1 or etch1 in the version number? The most recent changelog entry for both packages would be for "stable". Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Version numbering for security uploads of native packages
On Sun, 2008-03-16 at 11:22 -0700, Russ Allbery wrote: > "Adam D. Barratt" <[EMAIL PROTECTED]> writes: > > On Sun, 2008-03-16 at 09:06 +0100, Bas Wijnen wrote: [...] > >> Good idea. Even better, IMO, would be to use a system which is in > >> line with non-native packages. How about this rule: > > [using X.1] > >> IMO this solution is slightly better than +nmu1, because it makes > >> versions of native and non-native packages more uniformly mangled. > >> However, any solution is better than no solution. :-) > > > > That does seem the most logical suggestion thus far. > > I dislike this approach because it makes it impossible for tools like > Lintian to recognize NMUs of native packages and perform other > NMU-specific checks (such as making sure an appropriate changelog entry is > present). There's no way of knowing whether a native package with a > version number of 1.2.1 is an NMU or not. Indeed. Luk already pointed out on irc that this is the (or at least a) reason .1 wasn't suggested by DevRef. > I like the +nmuN approach. devscripts 2.10.19 including +nmuN was uploaded earlier this evening. Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Service stopping in prerm considered harmful
Ed Falk wrote, 2008-03-28 01:35: For the nth time squared, an initscript MUST NOT FAIL to stop an already stopped service. How is it supposed to do that? The service isn't running, so can't be stopped, therefore the script (if called to stop it) can only fail to stop it... If the service is already stopped, then the script should declare victory and return. Am I missing something? Yes - the fact that the comment you replied to was language pedantry rather than a technical argument. :) Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: uscan download URL mangling
Michal Čihař wrote, Monday, April 07, 2008 11:16 AM I currently have following, but it does not seem to work and the #md5= is not removed. opts="downloadurlmangle=s/#.*//" \ http://pypi.python.org/simple/python-mpd/ \ http://pypi.python.org/packages/source/p/python-mpd/python-mpd-(.*)\.tar\.gz#.* downloadurlmangle affects the URL that uscan downloads, not the filename that the result is saved under; for the latter you want filenamemangle: opts="filenamemangle=s/^.*(python-mpd-.*?\.tar\.gz)#.*$/$1/" \ http://pypi.python.org/simple/python-mpd/ \ http://pypi.python.org/packages/source/p/python-mpd/python-mpd-(.*?)\.tar\.gz#.* There may be a better solution, but the above does work. Regards, Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Rejected: epcr_2.3.9-1.dsc: sha1 check failed
Hi, Andreas Tille wrote: it is the third time that I've got this type of rejection. I faced it two times with package gnumed-client and now with a different package. [...] Rejected: epcr_2.3.9-1.dsc: sha1 check failed. Rejected: epcr_2.3.9-1.dsc: actual file size (1289) does not match size (1052) in .changes sha1 Rejected: epcr_2.3.9-1.dsc: sha256 check failed. Rejected: epcr_2.3.9-1.dsc: actual file size (1289) does not match size (1052) in .changes sha256 As Matthew said, you need to make sure you're using devscripts 2.10.25 so that debsign knows to update the file size in the new Checksums-* fields. fwiw, this was mentioned in the recent Misc Development News post to d-d-a. Regards, Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Rejected: epcr_2.3.9-1.dsc: sha1 check failed
Roberto C. Sánchez wrote, Thursday, April 17, 2008 2:24 AM On Wed, Apr 16, 2008 at 04:25:46PM +0100, Matthew Johnson wrote: do you have updated devscripts? debsign signs the dsc then updates the md5 hash in the changes before signing that. It needs to update the sha checks as well. The latest devscripts does. Will the devscripts in stable be updated to handle this? If so, when? If not, why not? (If you're looking for an answer from the maintainers of a package it's probably safer to ask them directly rather than assuming they read every post on debian-devel; admittedly several of us do, but... :-) I'm not convinced it meets the SRM team's criteria for a stable update, as laid out in http://release.debian.org/stable/4.0/4.0r3/ et al. 2.10.25 should migrate to testing over the weekend, so hopefully a bpo package won't be too much longer. In the meantime it's fairly easy to backport yourself, as several people have already done, or simply copy the new script over from an unstable machine. Other than the update for the new .changes file format, there have been relatively little changes to debsign since the version in etch, and those have all been bugfixes. Cheers, Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: NMU versioning (was: DEP1: Clarifying policies and workflowsfor Non Maintainer Uploads)
Raphael Hertzog wrote, Friday, April 25, 2008 3:16 PM On Fri, 25 Apr 2008, James Vega wrote: On Thu, Apr 24, 2008 at 09:42:59PM +0200, Bas Wijnen wrote: > This DEP is available on the Debian Wiki[1]. "The version must be the version of the last upload, plus +nmuX, where X is a counter starting at 1." The above was added to the DEP to "match dch" but dch only uses that format for native NMUs as per the earlier discussion on -devel[0]. Is this an intended change to usk +nmuX for all NMUs or should the wording be updated to reflect current behavior? I want a consistent versioning scheme, thus +nmuX for both native and non-natives packages. Consider this a wishlist bug against devscripts. :-) I was already intending to implement that, _assuming the DEP gains acceptance_. Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: How do I trace aptitude dependencies?
Russ Allbery wrote: "Bryan Donlan" <[EMAIL PROTECTED]> writes: Currently I have a situation where attempting to upgrade imagemagick from version 7:6.2.4.5.dfsg1-1+lenny1 to version 7:6.3.7.9.dfsg1-2+b1 pulls in over 200mb of dependencies, including mozilla-browser, iceape-browser, and half of gnome. Both devscripts and djvulibre have some really unfortunate Recommends right now. Most of the worst offenders in devscripts's case should have been fixed by now. Some of the remainder may not be ideal, but that mostly comes down to what one considers to be "important" functionality of the package, which we're well aware that there isn't exactly consensus on. Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: How do I trace aptitude dependencies?
On Mon, 2008-04-28 at 09:40 -0700, Russ Allbery wrote: > Goswin von Brederlow <[EMAIL PROTECTED]> writes: > > > I recommend to always do an upgrade before doing a dist-upgrade (or > > install of something pulling in 200mb). The upgrade will never install > > new or remove packages so it is save. It usualy reduces the number of > > packages to something where the search algorithm doesn't go wrong. > > This is what I used to do as well, but it doesn't seem to be working that > way any more. upgrade (and safe-upgrade) was pulling in a bunch of new > packages due to devscripts's Recommends. That should gradually be improving, as the Recommends have been trimmed for the majority of the recent uploads (including the as-yet-unuploaded 2.10.27). Some of them (e.g. citadel-*) are side-effects of issues with other packages. :-/ Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: morse package is "Architecture: any" but build daemons won't act
On Wed, 2008-05-07 at 21:45 +0200, Joop Stakenborg wrote: > It looks like the morse package isn't built by the build daemons, even > though it is "Architecture: any" in the control file. I think this > might be caused by the morse package in oldstable, which was a totally > different package with the same name and i386 only. > > Someone needs to trigger the build daemons, please? It's listed in Packages-arch-specific (http://cvs.debian.org/*checkout*/srcdep/Packages-arch-specific?root=dak) as being i386-specific. If that's no longer the case, you need to e-mail one of the people listed at the top of the file and ask them to remove it. Regards, Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: db.debian.org/password.html : Why ~/.ssh/id_dsa.pub to setup OpenSSH for RSA
On Wed, 2008-05-14 at 19:50 +0200, Luk Claes wrote: > Osamu Aoki wrote: > > Hi, > > > > Recent openssl issue lead me to http://db.debian.org/password.html and > > made me wonder why script example uses DSA key while main text only > > talks about RSA key. > > The text talks about RSA keys as they are preferred over DSA keys. I assume Osamu was confused by the fact that this paragraph mentions RSA consistently: > > | use SSH RSA Authentication > > to > > | access the servers. To setup OpenSSH for RSA you need to first generate a > > | private RSA key using ssh-keygen and select a good passphrase for it. > > Then send > > | the public portion of the key to the LDAP directory: and then suggests using the following: > > | gpg --clearsign < ~/.ssh/id_dsa.pub | mail [EMAIL PROTECTED] ^^^ in order to send your /RSA/ key :) (I'd guess the preceding text mentioned DSA at one point). Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: possible mass-bug filing on fc-cache-using packages
martin f krafft wrote, Tuesday, May 20, 2008 1:41 PM also sprach Josselin Mouette <[EMAIL PROTECTED]> [2008.05.20.1323 +0100]: > Le mardi 20 mai 2008 à 12:05 +0100, martin f krafft a écrit : > > if [ "$1" = configure -a -x /usr/bin/fc-cache ] > > Note -that the "$1" = configure check is wrong, see #446856. Also, the -a is a bashism, isn't it? It is, but one that policy 10.4 explicitly permits. Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: bashism question
Michael Meskes wrote, 2008-06-23, 10:07:27 +0200: With our move to dash as sh we have to remove all bashisms from scripts run by /bin/sh. However, checkbashism seems to moan about clauses that work in dash as well. I don't know in which shells a trap with a signal number is guaranteed to work, but it seems to work well in dash. It's not guaranteed to work in any shell implementing POSIX without extensions, which is what Policy says you're allowed to rely on (well, plus a few extensions, but not including trap and kill with signal numbers). In general the definition of bashism used by checkbashisms and lintian in this case is "not portable to a shell implementing SUSv3 2004 without extensions", with the potential exception of those explicitly allowed by Policy. I just ran a short test, so if the devil's in the detail I might have missed something, but nevertheless I wonder if this feature can safely be used. It's safe for use with dash, but using it is technically a violation of Policy (albeit a widespread one). There is a Policy bug open requesting that the XSI extensions for trap and kill be permitted (#477240). Regards, Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: bashism question
On Mon, 2008-06-23 at 19:28 +0200, Michael Meskes wrote: > On Mon, Jun 23, 2008 at 05:39:07PM +0100, Adam D. Barratt wrote: > > It's not guaranteed to work in any shell implementing POSIX without > > extensions, which is what Policy says you're allowed to rely on (well, > > plus a few extensions, but not including trap and kill with signal > > numbers). > > Right. But what does this mean in terms of our Lenny release goal "dash as > sh" which essantially was what I meant to ask. I'd assume it doesn't make any difference in terms of that release goal as (as you noted) dash supports the syntax. > > It's safe for use with dash, but using it is technically a violation of > > Policy (albeit a widespread one). There is a Policy bug open requesting > > that the XSI extensions for trap and kill be permitted (#477240). > >From this I'd say for Lenny using trap with a signal number is fine. As fine as it was for etch :-) > Also they same question comes up with the "local" keyword. Dash seems to > support this, while it is not POSIX. Policy contains an explicit exemption for "local", although it places several restrictions on exactly how the keyword may be used. Again, if dash supports the syntax then the "dash as sh" release goal is achievable without changing the code; whether that code is Policy compliant is another matter. Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: bashism question
On Mon, 2008-06-23 at 19:45 +0200, Michael Meskes wrote: > On Mon, Jun 23, 2008 at 01:33:21PM -0400, James Vega wrote: > > > >From this I'd say for Lenny using trap with a signal number is fine. > > > > > > Also they same question comes up with the "local" keyword. Dash seems to > > > support this, while it is not POSIX. > > > > The "local" keyword is an explicitly supported extension. These are > > discussed in Section 10.4 of policy. > > Thanks to James and Adam for the explanations. Maybe I could ping the > devscripts maintainers to add a not-xsi-but-supported-by-policy flag. > :-) /me coughs in the direction of devscripts' Uploaders field (I'm assuming you'd noticed, but just in case :-) Assuming "not-POSIX-but-supported-by-policy" checkbashisms already has a flag to indicate whether "echo -n" should be flagged for exactly this reason; otherwise it errs on the side of not flagging constructs that are policy-compliant. Supporting "local x" would be relatively simple; suggestions for a reliable regex to catch use of -a/-o welcome... :) Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: bashism question
On Mon, 2008-06-23 at 17:52 -0700, Russ Allbery wrote: > "Adam D. Barratt" <[EMAIL PROTECTED]> writes: > > > Supporting "local x" would be relatively simple; suggestions for a > > reliable regex to catch use of -a/-o welcome... :) > > There was a fairly good one in Lintian that I took out once Policy blessed > it, or at least we didn't get a lot of false positive reports. Thanks; that looks like it stands a good chance of being resilient. Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: bashism question
On Tue, 2008-06-24 at 09:34 -0500, Raphael Geissert wrote: > Russ Allbery wrote: > > > "Adam D. Barratt" <[EMAIL PROTECTED]> writes: > > > >> Supporting "local x" would be relatively simple; suggestions for a > >> reliable regex to catch use of -a/-o welcome... :) > > > > There was a fairly good one in Lintian that I took out once Policy blessed > > it, or at least we didn't get a lot of false positive reports. > > > > Maintainer scripts are fairly simple so I don't think there will be many > false positives ;) The expression looks fairly robust and passes my testing so far; admittedly the archive is full of scripts that break almost every assumption I ever made about shell scripting. This is getting a little off-topic for -devel I think :) Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: bashism question
On Tue, 2008-06-24 at 13:36 +0200, Michael Meskes wrote: > On Mon, Jun 23, 2008 at 07:00:13PM +0100, Adam D. Barratt wrote: > > Assuming "not-POSIX-but-supported-by-policy" checkbashisms already has a > > flag to indicate whether "echo -n" should be flagged for exactly this > > reason; otherwise it errs on the side of not flagging constructs that > > are policy-compliant. > > It does flag both, trap and local. This is how I came to my question. As per previous messages, the uses of trap flagged aren't policy compliant; the uses of local being flagged should also be those which aren't policy compliant - if that's not the case, it's a bug in checkbashisms. To be precise, the current tests flag the use of "local foo=bar" and "local -n foo" as neither is supported by policy; "local x" is permitted and therefore not flagged. The next release of checkbashisms will include a "--posix" flag which will allow the non-POSIX behaviours permitted by policy to be flagged. Currently neither set of "local" checks flags "local x, y"; I seem to remember there being a discussion relating to that syntax on the -policy list a while ago but need to check whether it reached any conclusions. Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: bashism question
Adam D. Barratt wrote: [...] The next release of checkbashisms will include a "--posix" flag which will allow the non-POSIX behaviours permitted by policy to be flagged. Currently neither set of "local" checks flags "local x, y"; I seem to remember there being a discussion relating to that syntax on the -policy list a while ago but need to check whether it reached any conclusions. Actually, ignore that. I was thinking of "local a b" which policy explicitly says can't be relied upon. Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: bashism question
Lars Wirzenius wrote:
To clarify: is "local foo=bar" policy-compliant or not?
(If not, *sigh*.)
To the best of my knowledge, no, it's not compliant. The relevant section
reads:
* `local' to create a scoped variable must be supported; however,
`local' may or may not preserve the variable value from an outer
scope and may or may not support arguments more complex than
simple variables. Only uses such as:
fname () {
local a
a=''
# ... use a ...
}
must be supported.
As "foo=bar" is an argument "more complex than simple variables" and the
example explicitly shows the use of local to declare the variable followed
by assignment to it, my reading of policy is that "local foo=bar" is not
permitted.
Adam
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Lintian based autorejects
Brian May wrote: On Tue, Oct 27, 2009 at 02:57:35PM +, Simon McVittie wrote: - statically-linked-binary This is not always a bug. e.g. dar-static is supposed to be statically linked! Lintian intentionally doesn't warn about binaries with names ending -static, hence the non-appearance of dar-static on http://lintian.debian.org/tags/statically-linked-binary.html Cheers, Adam -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: xulrunner, poppler, gnome and gupnp transitions
On Sun, 2009-11-08 at 12:48 +0100, Luk Claes wrote: > * gupnp > - libnice not yet rebuilt/reuploaded libnice was binNMUed as part of this transition so shouldn't be a blocker. The remaining issue that I can currently see here is gupnp-igd being out-of-date on mips. Adam -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: xulrunner, poppler, gnome and gupnp transitions
On Sat, 2009-11-14 at 15:45 +0100, Luk Claes wrote: > Josselin Mouette wrote: [...] > > Le dimanche 08 novembre 2009 à 12:48 +0100, Luk Claes a écrit : [...] > >> - empathy not built on kfreebsd* > > > > It’s waiting on geoclue, which in turn needs disabling of gammu support > > on !linux. > > There does not seem to be any bug filed about this, is there any > progress in that regard? #556178 was filed against geoclue this morning, but has already been marked as wontfix and closed. The suggestion was to modify gammu to build without libusb support on !linux, but there doesn't appear to be any open request to do that. In either case, geoclue also Build-Depends on network-manager-dev, which is not available on kfreebsd-*; removal of the build-dep on those architectures was also requested in #556178. Adam -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Is a README.Source required for the new package formats?
On Thu, 2009-11-19 at 15:24 -0800, Rodrigo Gallardo wrote: > lintian is complaining about a package of mine I just converted to 3.0 > (quilt) that: > > W: rep-gtk source: patch-system-but-no-source-readme [...] > But, since dpkg-source will extract this package into the preferred > form for modification, and since I didn't even add quilt as > Build-Depends, should I consider this a bug in lintian? No, you should upgrade your copy of Lintian to 2.2.18, which no longer issues the warning. From the changelog: * checks/patch-systems: + [RA] Do not issue patch-system-but-no-source-readme for packages in 3.0 (quilt) format. Patch from Stéphane Glondu. (Closes: #553207) Regards, Adam -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: ITP: lhapdf -- Les Houches Accord PDF Interface
Hendrik Sattler wrote: > Am Mittwoch 17 Januar 2007 12:34 schrieb Luca Capello: >> Please the next time use the X-Debbugs-CC: header [1] instead of [...] > Will b.d.o accept those headers in the first lines of a mail body? Yes (at least, it should). See #179340 against debbugs, currently flagged as pending (which generally means it's deployed on bugs.d.o but isn't in a released debbugs package). Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: about gstreamer0.8 and python2.3 removal
On Fri, 2007-02-09 at 20:57 +0200, Tshepang Lekhonkhobe wrote: > Hi, > > It's been a while since someone mentioned removal of gst0.8 and py2.3 > and wonder what's going on. python2.3 is no more, as of a month ago today: python2.3 | 2.3.5-3sarge1 |stable | source, alpha, arm, hppa, i386, ia64, m68k, mips, mipsel, powerpc, s390, sparc python2.3 | 2.3.5-3sarge2 | proposed-updates | source, alpha, arm, hppa, i386, ia64, m68k, mips, mipsel, powerpc, s390, sparc Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Source package taking over removed package's place in the namespace
Magnus Holmgren wrote, Thursday, May 31, 2007 1:04 PM Situation: Two source packages collide in the namespace. The second one gets rather awkward name. Later, the first package dies and is removed from unstable, testing, and (after release) stable, but still remains in oldstable. Question: Can the second source package take the first source package's (less awkward) name, or does it have to wait until oldstable is archived? So far as I can tell, that should be fine. dak requires that (source, version) tuples be unique, so the new source package would need to have a different (practically, higher) version than the old one; that's not a problem in this case. Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Filing FTBFS bugs and packages in NEW
Ron Johnson wrote: On 06/01/07 04:59, Kari Pahula wrote: I'd like to file a wishlist bug on people who file FTBFS bugs. It would be nice if you checked first whether there's a package pending in NEW or incoming and see if that might resolve the issue already. I'm looking at you, #426867. Even though "I" am not #426867, how do you access the NEW queue? For appropriate values of "access" - http://ftp-master.debian.org/new.html Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#427297: ITP: sturmbahnfahrer -- simulated obstacle course for automobiles
On Mon, 2007-06-04 at 21:33 +0200, Izak Burger wrote: [...] > But no-one said english was logic :-) What with unkempt (no such word > as kempt though) I didn't think there was, but http://www.askoxford.com/concise_oed/kempt?view=uk disagrees ;) Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Using standardized SI prefixes
On Wed, 2007-06-13 at 14:08 -0400, Felipe Sateler wrote: > Mike Hommey wrote: > > > On Tue, Jun 12, 2007 at 09:25:13PM +, Evgeni Golov > > <[EMAIL PROTECTED]> wrote: > >> On Tue, 12 Jun 2007 15:42:08 -0300 Paulo Marcondes wrote: > >> > >> > billion = 10^6 * 10^6 (IIRC, as used in Portugal - no jokes here!) > >> > >> =10^12 :) > >> > >> and Germany, France, former UdSSR, > > > > Anywhere where milliard is 10^9, basically... > > Which includes England, according to Merriam-Webster [1]. [...] > [1] http://www.m-w.com/mw/table/number.htm The American usage has been becoming more common in England (and the rest of Britain :-) over the past few years, particularly in science and finance related usage. I could be wrong, but I suspect most British people have never even heard of a milliard. It's usually referred to either as a billion or an "American billion". Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Problems with closing certain bugs
On Fri, 2007-06-29 at 12:58 -0400, Daniel Schepler wrote: > I appear to be unable to close certain bugs lately, while others work fine. > One earlier example was #205163, which I was trying to close as it was fixed > a long time ago. Then yesterday closing #379237 and #387587 worked, but in > the same message my attempt to close #378102 was rejected. With both #205163 > and #378102 I got a bounce message saying that [EMAIL PROTECTED] was > an "unknown user". #205163 and #378102 are both archived (and therefore by definition also closed). Modifications to archived bugs aren't possible, so debbugs won't accept mail for them. [#205163 was closed in October 2003 so would have been archived some time in November 2003. #378102 was closed in July 2006 whilst archiving was disabled and finally archived on June 17th this year.] FWIW, I'm guessing the two bug numbers may have been typos as #378102 is a mysql security bug and #205163 a translation for gnapster whereas your closure message refers to gcc. Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#491156: ITP: postgresql-8.3-plr -- Procedural language interface between PostgreSQL 8.3 and R
Andreas Tille wrote: On Thu, 17 Jul 2008, Thomas Viehmann wrote: The package was removed after noone was interested in maintaining it for four(!) years. Huh? [...] * Orphan package (see #228074). -- Martin Pitt <[EMAIL PROTECTED]> Sun, 30 Dec 2007 20:38:42 +0100 That's about 6 month and not four years. #228074 is an RFA for the package, filed in January 2004 and with no sign of any interest. Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [VAC] August 08
On Fri, 2008-08-01 at 16:28 +0200, Thibaut Paumard wrote: > PS: I'm not sure how DM's are supposed to deal with VAC notices, as > (I far as I know) we don't have access to -private. Anyone can post to -private; I tend (as a DM) to cc my VAC notices there, which has elicited a couple of (quite useful) responses in the past. Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#161978: this really should be checked by lintian
Hi,
On Mon, August 25, 2008 11:56, Holger Levsen wrote:
> downgrading severity, as this is about an old issue with tetex and because
> there is probably even a lintian check for this already. (Too lazy to
> confirm
> now, thus I'm also not reassigning the bug to lintian yet.)
As far as I can see, the section of the bug report regarding tetex relates
to shipping content in /usr/local; if that's the case then it will indeed
be flagged by lintian, as {dir,file}-in-usr-local (both Error tags).
Adam
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: bug closed by spam for the second times
[EMAIL PROTECTED] wrote: OK, this reopens and also reports. [...] echo reopen $bug| mail -s "Reopening $bug closed by spam" [EMAIL PROTECTED] w3m -dump "http://bugs.debian.org/cgi-bin/bugspam.cgi?bug=$bug;ok=ok"; else echo If you've got devscripts installed, then "bts reopen $bug . reportspam $bug" will do the same. Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: bug closed by spam for the second times
Vincent Danjean wrote: Adam D. Barratt wrote: If you've got devscripts installed, then "bts reopen $bug . reportspam $bug" will do the same. I suppose that the 'reportspam' command does the same thing as the link 'Send a report that this bug log contains spam' on the bts webpage ? Yes. It GETs the URL that the link refers to. * Verify report for bug 343140 Yes, report bug 343140 as spam * and I did not validate here because I was not sure if the whole bug #343140 would be maked as spam or only some part of it. There's at least #498257 requesting that the text be clarified (I may have missed others, I remember that report as it was filed a few hours ago). Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: List of RC-buggy source packages by maintainer/uploader
On Tue, 2008-10-07 at 05:56 +0200, Lucas Nussbaum wrote: > On 06/10/08 at 18:36 -0500, Raphael Geissert wrote: > > Lucas Nussbaum wrote: [...] > > > Steve Langasek <[EMAIL PROTECTED]> > > >firmware-nonfree (U) > > >mklibs (U) > > >openldap (U) > > >php5 (U) > > > > Steve stepped down from php's maintenance a couple of uploads ago (he is no > > longer in Uploaders even in the version in lenny); looks like a bug > > somewhere in UDD. > > I'm not sure how dd-list really works. I just ran dd-list to generate > the per-maintainer list. It runs "apt-cache showsrc" (which doesn't include Steve here for php5 on sid). Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Britney error with the gossip package?
On Tue, 2008-10-07 at 20:21 +0100, Neil Williams wrote: > $ rmadison libloudmouth1-0 > > libloudmouth1-0 |1.4.0-1 | testing | alpha, amd64, arm, > armel, hppa, i386, ia64, mips, mipsel, powerpc, s390, sparc > libloudmouth1-0 |1.4.2-1 | unstable | alpha, amd64, arm, > armel, hppa, hurd-i386, i386, ia64, m68k, mips, mipsel, powerpc, s390, > sparc > > How did gossip migrate with Build-Depends on a version of > libloudmouth1-0 that still does not exist in Lenny? britney only considers installability, not buildability. That is to say, if package A depends on "B (>= 2)" then an appropriate version of B must (in the absence of hints to the contrary) exist in testing, but if A /build/-depends on "B (>= 2)" then britney does not care whether B exists in testing at all, yet alone with the correct version. Regards, Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#503087: ITP: openvpn-auth-ldap -- The OpenVPN Auth-LDAP Plugin implements username/password authentication via LDAP for OpenVPN 2.x.
Hi, Brivaldo Alves da Silva Jr wrote: Package: wnpp Severity: wishlist Owner: Brivaldo Alves da Silva Jr <[EMAIL PROTECTED]> I want to add this functionality to OpenVPN to auth on OpenLDAP. There's already a package of openvpn-auth-ldap (packaged by Debian's openvpn maintainer) in the NEW queue, waiting to be processed by the ftpmasters. http://ftp-master.debian.org/new/openvpn-auth-ldap_2.0.3-1.html Regards, Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#503087: ITP: openvpn-auth-ldap -- The OpenVPN Auth-LDAP Plugin implements username/password authentication via LDAP for OpenVPN 2.x.
Hi, Thanks, How can I close this bug? Just e-mail [EMAIL PROTECTED] I've done that with this mail, so the bug should now be closed (or will be in a few minutes time). Regards, Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#503367: [Debian-med-packaging] Bug#503367: plink: file conflict with putty-tools
On Sat, 2008-10-25 at 20:18 +0300, Teodor wrote: > Since renaming seems to be the only solution, than IMO it is more > appropriate to rename 'plink' in putty-tools than in the plink > packages since this is exactly the source/binary package name. [...] > This has been done already in putty-tools for the 'puttygen' binary. [...] > piti:~# dpkg -L putty-tools > [snip] > /usr/bin/pscp > /usr/bin/psftp > /usr/bin/plink > /usr/bin/puttygen Erm, puttygen isn't renamed. That's what the upstream binary is known as and has been ever since its creation more than four years ago (although more often puttygen.exe for predictable reasons). Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: can buildd logs be sorted (again)?
On Wed, 2008-10-29 at 12:47 -0600, Raphael Geissert wrote: > Peter Palfrader wrote: > > > On Wed, 29 Oct 2008, Patrick Matthäi wrote: > >> > >> You should report a bug against qa.debian.org / www.debian.org. > > > > Neither of those is the correct contact/package regarding > > buildd.debian.org. I guess we don't have a metapackage for w-b and > > buildd.d.o. Maybe eventually that will be fixed. > > *cough*, what about contacting Ryan Murray? he is the one listed at buildd.d.o In this specific case, he was already CCed on Steve's mail which began this thread... Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Possibly excessive lintian warnings (was: NEW processing)
On Thu, 04 Dec 2008 01:00:17 -0800, Russ Allbery wrote: Sune Vuorela <[EMAIL PROTECTED]> writes: Latest, the warning about quilt patches without any description. Sure it is nice to have a description, but I don't need lintian to tell it. This is severity: minor, certainty: certain, which currently *barely* makes the W threshold. I think a very good argument could be made that this is actually severity: wishlist, which would downgrade it to an I. I'm copying debian-lint-maint to see what the other Lintian maintainers think. As I mentioned to Sune on IRC last night, the quilt tag's severity was copied from the equivalent dpatch tag (which was originally implemented as a warning and then moved to minor/certain during the transition). I've no problem with downgrading the severity, although we should make a corresponding change to the dpatch tag at the same time, unless there's some reason it's particularly worse for a dpatch to be missing a description. Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: NEW processing
On Wed, 03 Dec 2008 20:28:59 -0600, Raphael Geissert wrote: From the lintian hacker desk: $ lintian -I --exp-output format=letterqualifier [...] Other *experimental* output formats are 'xml' and 'colons' (currently b0rken). It's fixed in HEAD (well, it now works for me). Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Possibly excessive lintian warnings
On Thu, 2008-12-04 at 12:51 -0800, Russ Allbery wrote: > "Adam D. Barratt" <[EMAIL PROTECTED]> writes: > > > As I mentioned to Sune on IRC last night, the quilt tag's severity was > > copied from the equivalent dpatch tag (which was originally implemented > > as a warning and then moved to minor/certain during the transition). > > > > I've no problem with downgrading the severity, although we should make a > > corresponding change to the dpatch tag at the same time, unless there's > > some reason it's particularly worse for a dpatch to be missing a > > description. > > I think they're equivalent cases. Personally, I vote for downgrading them > both. I agree... > Unless there are any objections, I'll do that in a bit. ... and did that an hour ago. Apologies for not waiting a little longer for objections / consensus. Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Test suites after build and Build-Depends.
On Fri, 2009-01-30 at 09:00 -0800, Russ Allbery wrote: > Charles Plessy writes: > > In reality, it is an endangered mechanism, as it was deprecated in > > January 2008. > > I'm not sure what you're referring to here. I'd guess Charles meant the following addition to README.feature-removal-schedule, from the dpkg source package: What: substvars support in dpkg-source and dpkg-genchanges Status: deprecated When: lenny+1 Warning: program Why: substvars do not make sense during generation of .dsc and .changes files. This also means that it won't be possible anymore to override the Format field output by dpkg-genchanges. Adam -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Bug#434206: ITP: moe -- powerful text editor for ISO-8859 and ASCII character encodings
Neil Williams wrote, Wednesday, July 25, 2007 10:07 AM On Wed, 25 Jul 2007 14:13:23 +0530 "Kumar Appaiah" <[EMAIL PROTECTED]> wrote: [...] > OK. It's in the NEW queue. Could you please tell me the procedure to > prevent it from entering the archives? Retitle the ITP to a RM http://wiki.debian.org/ftpmaster_Removals and explain why. You can't remove something that's not in the archive... Probably best to also send an email (referencing this thread in the debian-devel archives) to [EMAIL PROTECTED] asking for the package to be rejected from NEW. The release team don't manange NEW. Kumar, you need to e-mail [EMAIL PROTECTED] and ask them to reject the upload from the NEW queue. Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFC: changes to default password strength checks in pam_unix
On Tue, 2007-09-04 at 07:53 +, Oleg Verych wrote: [...] > What about having more secure Debian's sshd_config by default? > " > PermitRootLogin no You'll have to convince the openssh package maintainers first - see #105571, #298138 and #431627 for their opinions on whether that change is "more secure". Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Releasing packages with 'pending' RC bugs
Daniel Baumann wrote, Thursday, September 27, 2007 11:43 AM out of curiousity.. imagine a package where: * the Debian maintainer is also upstream maintainer * the package has practically no users (popcon << 10) * the package has RC bugs * the RC bugs are fixed upstream * the RC bugs are tagged pending in the BTS * the fixed package doesn't get uploaded (e.g. due to ENOSPONSOR) If I am not wrong (otherwise please do correct me) such a package would enter testing on the normal way, and hence, would be part of the upcoming stable release. You're wrong. Assuming that the RC bugs are not present in testing already, the testing scripts will not allow the package to migrate. Tagging bugs as pending does not stop them being RC and makes no difference to their impact on testing migration. If the package in testing is RC buggy it will get removed by the release team before release anyway. Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: reportbug and usertags
On Tue, 2007-11-13 at 12:14 -0800, Don Armstrong wrote: [User: and Usertags: in reportbug-generated mails not reaching the BTS] > Sounds like a bug in reportbug to me; it's probably stripping out > unknown pseudoheaders. Indeed; see #418677 and #445144, both currently filed at wishlist against reportbug. Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Package upgrade in Debian without corresponding changelog entry
On Sat, 2010-01-30 at 10:20 +1100, Ben Finney wrote:
> Occasionally I notice a package upgrade on a host, but the Debian
> changelog for the package has no corresponding changelog entry for the
> new release.
>
> The most recent example is ‘mercurial’:
>
> =
> $ PACKAGE=mercurial
>
> $ dpkg-query -W -f 'Version: ${Version}\n' $PACKAGE
> Version: 1.4.1-1+b1
>
> $ zcat /usr/share/doc/$PACKAGE/changelog.Debian.gz | dpkg-parsechangelog -l-
> | grep '^Version:'
> Version: 1.4.1-1
> =
mercurial's changelog is symlinked to mercurial-common's.
mercurial-common is arch:all and therefore not rebuilt by binNMUs.
Regards,
Adam
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Bug#570980: reportbug general bug filing recommendation (was Re: Bug#570980: man sbin man pages are in section 1 instead of section 8
# Cc to -devel for information after the reassign merge 570980 348864 thanks Holger Levsen wrote, Monday, February 22, 2010 5:19 PM clone 570991 -1 reassign -1 lintian retitle -1 "please add a check against commands in /sbin using section 1 manpages" fwiw, there *was* such a lintian check, which was removed as the section 1/8 division is not exactly the same as the bin/sbin division. At least last time I can find it being discussed, the man-db maintainer agreed with not having the check (see #348864, with which I've just merged this bug). In fact, that log appears to include a piuparts maintainer arguing that piuparts(1) is correct despite the program being in /sbin. ;-) Regards, Adam -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/a1f30f3718324e178245fddf8eefa...@internal.avcosystems.com
Re: Decoupling GNOME 2.30 transitions
On Sun, March 28, 2010 12:54, Josselin Mouette wrote: > 3 - totem-pl-parser (libtotem-plparser12 â libtotem-plparser17) > + evince (libevince1 â libevince2) As discussed on IRC, please go ahead with these: > Sourceful uploads: > brasero > evince > gnome-python-desktop > totem > totem-pl-parser Regards, Adam -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/05e3a46e7f3adeab1038c7ac170a6e01.squir...@sheerkahn
Re: [OSRM] Planning for final Etch point release and archiving of oldstable?
On Sat, May 8, 2010 18:06, Frans Pop wrote: > I would have expected a final point release for Etch to have happened by > now (since security support was ended back in February). My personal > interest is of course the D-I updates included for that release. Regrettably, sorting out etch hasn't had the priority we'd have liked for a little while. However, we have been making progress recently. We now have copies of all the packages from DSAs (with one exception where the .orig tarball used for the security update differs from that in the main archive) and have been working on trying to build the few remaining packages where for some reason the security update failed to build on an architecture supported by the package. I think we're more or less at the point where we should admit defeat with the couple of packages that still fail; we then just need to organise the actual release. Regards, Adam -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/8935ac7d1f083dfedd1c0b76b4b5219d.squir...@adsl.funkybadger.org
Re: Waiting for SCons 2.0: rebuild test
Hi, On Fri, 2010-06-04 at 16:30 +0200, Luca Falavigna wrote: > So, I rebuilt reverse dependencies of SCons to spot some problems, and I > published my results online. Here is a brief summary: > > * 58 packages build-depending on SCons > * 53 packages built successfully (2 of them needed sourceful changes, > such as build-dependency mangling or so, but not related to SCons). > * 4 packages FTBFS: > * 1 package has temporary dependency screwup What specifically does "temporary dependency screwup" mean? > I have already informed upstream of my rebuild tests, and I hopefully > will be given instructions on how to properly fix FTBFSes, which I will > report as important bugs against affected packages. SCons 2.0 release > should happen in June, if RT does not mind, I intend to upload 2.0 to > unstable shortafter. I'm assuming that this is "just" a new upstream version? i.e. once the FTBFS packages are fixed and assuming no RC issues in scons itself appear, there'd be no need for any explicit action from the Release Team and SCons 2.0 would simply transition to testing once its 10 days were up? Regards, Adam -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1275676646.30695.537.ca...@kaa.jungle.aubergine.my-net-space.net
Re: chromium-browser from experimental has included h.264 by default?
On Tue, 2010-05-11 at 20:55 +0200, Moritz Muehlenhoff wrote: > On 2010-05-11, Reinhard Tartler wrote: > > Surely not. Chromium ships a *private* copy of ffmpeg, more precisely, a > > fork of ffmpeg called ffmpeg-mt. Debian does not include ffmpeg-mt > > because of bug #575600 (tagged wontfix). Moreover, Debian's copy of > > ffmpeg will always be out-of-date. > > > > I wonder why the security team hasn't vetoed this move... > > Chromium isn't meant to be released with Squeeze. We'll reevaluate for > Squeeze+1. Is that still the case? chromium-browser isn't in squeeze yet, but the only thing holding it out right now is the fact that we haven't finished the icu transition and chromium-browser depends on libicu44. Regards, Adam -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1281468359.5975.292.ca...@kaa.jungle.aubergine.my-net-space.net
sendmail 8.1.4.4-1(was: Re: Richard A Nelson (Rick) MIA)
On Tue, 2010-11-02 at 08:09 +0100, Harald Jenny wrote: > On Mon, Nov 01, 2010 at 04:48:08PM -0700, Richard A Nelson wrote: > > On Mon, 1 Nov 2010, Harald Jenny wrote: > > >Could you give us a quick overview what the current state of > > >packaging sendmail and libmilter is? Do you need any help? Is there a > > >chance to > > >get this new version still into Squeeze (release team?) or should we rather > > >focus on backporting the necessary changes to 8.14.3? As the libmilter > > >problem > > >renders a class of applications unreliable this should IMHO really be > > >classified as RC bug. [...] > > sendmail_8.14.4-1_amd64.changes ACCEPTED into unstable [...] > > So, barring bugs, it should hit testing soon > > Thanks - and I hope the release team will allow this transition to take place. Which libmilter problem are you referring to? There don't appear to be any RC bugs closed by the upload. With a little massaging of the diff (tarball-in-tarball with versioned directory names sucks), I can get down to 146 files changed, 2092 insertions(+), 999 deletions(-) but that's still quite large for an update at this point. :-/ Regards, Adam -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1289134326.27850.6045.ca...@hathi.jungle.funky-badger.org
Re: sendmail 8.1.4.4-1(was: Re: Richard A Nelson (Rick) MIA)
[please drop -devel from further follow-ups; this is drifting further off-topic there] On Sun, November 7, 2010 22:05, Harald Jenny wrote: > On Sun, Nov 07, 2010 at 12:52:06PM +0000, Adam D. Barratt wrote: >> On Tue, 2010-11-02 at 08:09 +0100, Harald Jenny wrote: >> > On Mon, Nov 01, 2010 at 04:48:08PM -0700, Richard A Nelson wrote: >> > > sendmail_8.14.4-1_amd64.changes ACCEPTED into unstable >> [...] >> > > So, barring bugs, it should hit testing soon >> > >> > Thanks - and I hope the release team will allow this transition to >> take place. [...] >> Which libmilter problem are you referring to? There don't appear to be >> any RC bugs closed by the upload. > > Well I tried to change bug > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=527862 > to severity grave as I thought this would make this a release-critical bug > but failed to do so, please see the last mail in the thread before the > solved message (not enough experience with bugs.debian.org yet). Yes, you need to use the control@ bot, not just include a "Severity:" header in a follow-up. >> With a little massaging of the diff (tarball-in-tarball with versioned >> directory names sucks), I can get down to >> >> 146 files changed, 2092 insertions(+), 999 deletions(-) >> >> but that's still quite large for an update at this point. :-/ > > I know this but the above mentioned bug make almost any software depending > on libmilter unusable (or at least unstable) and as this release was > uploaded to unstable already it won't be possible to only get the > important changes for libmilter in an updated 8.14.3 version. Well, it /could/ be updated via tpu still, if someone can isolate the changes required and produce a proposed diff. I'm really not overly keen on importing a new upstream version in to testing at this point, after 18 months with no maintainer uploads and a handful of NMUs. Regards, Adam -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/f1fe90dc0e9f5715a7b384fd7c21f2c8.squir...@adsl.funky-badger.org
Re: Bug#605912: runit: Upgrade failure lenny -> squeeze
# CC to debian-devel for squeeze blocker user release.debian@packages.debian.org usertag 605912 + squeeze-is-blocker thanks Hi, Thanks for looking at this bug. I think the patch you've suggested is the wrong solution, however. On Tue, 2011-01-04 at 01:14 +0900, Hideki Yamane wrote: > I guess it is due to lack of flag in debconf templates file. > Here's a proposal patch, it works in my chroot environment. [...] > +runit (2.1.1-6.2) unstable; urgency=low > + > + * Non-maintainer upload. > + * debian/control > +- add missing depenedency "debconf (>= 0.5) | debconf-2.0" > + * debian/runit.templates.in > +- add "runit-run/install" (Closes: #605912) The code in the config script which sets the runit-run/install flag as seen (which is where this bug comes from) is guarded by a check for upgrades from versions >= 2.0.0-1, which is the version in lenny. However, runit only ever suggested runit-run, so the code was always broken. As runit-run no longer exists after lenny, I think removing the entire block of code would be a better solution. In terms of the second part of the patch, the package's use of debconf looks a little odd. There is one template, which says "can I signal init to restart?". Previously, the signalling was performed without asking, which broke in environments where there was no such process, such as vservers (see #542593). The implemented solution asks this question at low priority if an init process is found, and high priority if not; in both cases the default is "yes", which does not seem to make much sense in the case where it has already been determined that there is no such process. It's possible that I simply need more coffee, but it may make more sense to simply rip the debconf use back out, and have the postinst signal init based simply on the existence of an init process. Comments welcome. Regards, Adam -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1294505796.2903.5925.ca...@hathi.jungle.funky-badger.org
Re: /etc/profile.d
On Mon, January 10, 2011 09:57, Nicholas Bamber wrote: > According to #370348, since 5.3 base-files has supported /etc/profile > sourcing /etc/profile.d. I am using version 6.0. > However /etc/profiles seems to be doing no such thing. When was the system in question installed? The changelog for base-files 5.3 says (emphasis mine) "Changed *default* /etc/profile so that it sources /etc/profile.d/*.sh"; /etc/profile is generated from the default file at initial install and not touched on upgrades, so if the system was installed with an earlier base-files version then you won't automatically get /etc/profile.d support. You can check /usr/share/base-files/profile in order to verify that the default file does include profile.d support. Regards, Adam -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/43e38a1e3a5c2d49e280cfd8e2163236.squir...@adsl.funky-badger.org
Your pdf-presenter-console upload
Hi, I was just having a look at the diff for your upload of pdf-presenter-console 1.1.1+git.02dfcf-3, fixing #609608, to check if it was suitable for unblocking for squeeze. Firstly, thanks for fixing the bug so quickly. Unfortunately, the upload included a couple of other changes which aren't really appropriate at this point of the freeze, specifically + * dh --parallel + * dh 8 One of the other changes means that the package is currently unbuildable in unstable: + * bump valac build-depends to 0.9.7+ per README.rst (debian/control) I've reported this as #609676. Regards, Adam -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/db7c866dcc3fe5258571e8afa2cfbbbf.squir...@adsl.funky-badger.org
Re: Your pdf-presenter-console upload
Gah, that was intended for debian-release, not debian-devel; please direct follow-ups to -release. On Tue, January 11, 2011 13:18, Adam D. Barratt wrote: > Hi, > > I was just having a look at the diff for your upload of > pdf-presenter-console 1.1.1+git.02dfcf-3, fixing #609608, to check if it > was suitable for unblocking for squeeze. > > Firstly, thanks for fixing the bug so quickly. Unfortunately, the upload > included a couple of other changes which aren't really appropriate at this > point of the freeze, specifically > > + * dh --parallel > + * dh 8 > > One of the other changes means that the package is currently unbuildable > in unstable: > > + * bump valac build-depends to 0.9.7+ per README.rst (debian/control) > > I've reported this as #609676. > > Regards, > > Adam > > > -- > To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org > with a subject of "unsubscribe". Trouble? Contact > listmas...@lists.debian.org > Archive: > http://lists.debian.org/db7c866dcc3fe5258571e8afa2cfbbbf.squir...@adsl.funky-badger.org > > > -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/52862eb945a9ea3a838e47639dc46b09.squir...@adsl.funky-badger.org
Re: "Mass" (non invasive) NMUs planned to fix debconf translations broken in multiple packages
On Wed, 2011-01-12 at 19:43 +0100, Christian PERRIER wrote: > My plans are to upload before the end of the upcoming week-end an NMU > for each of the affected package(s). > > I currently have: fwiw, from a quick look at the list, at least boxbackup would need a t-p-u upload in order to get fixed for squeeze; likewise bugzilla from Julien's original list. Regards, Adam -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1294861399.9806.198.ca...@hathi.jungle.funky-badger.org
Re: security updates introducing breakage
On Thu, January 20, 2011 03:18, Paul Wise wrote: > On Thu, Jan 20, 2011 at 10:59 AM, Brian May > wrote: > >> What is policy when security updates for stable introduce new >> regressions in software that weren't there before? Can these get fixed >> in stable? > > If a stable security update contained a regression, usually that is > fixed with an update in the stable security archive. Please ping the > maintainer and CC the security team about this. You will also want to > unarchive the bug so that it can be closed again. Indeed, if an update via stable-security introduces regressions then these will usually be fixed via a further upload to stable-security. In this case, although the update was security related, it was actually made via proposed-updates as part of the 5.0.5 point release. Much the same applies in cases such as this, however. Alerting the maintainer should be the first step, with a CC to the Release Team being appreciated. > I also wonder why the security team didn't pick this up, I guess they > don't have any automatic tracking of bugs filed against versions they > uploaded. I can't speak for the security team, but it's non-trivial for the Release Team to track all bugs filed against the version of a package in lenny and then determine whether the problem could have been introduced in a stable update. There's some great ongoing work to help ensure that RC bugs are correctly tagged and versionned to indicate whether they affect stable releases, and to help get them fixed where it's been determined that they do. For lower severity bugs, we do very much rely on maintainers and other interested parties bringing the issue to our attention. Once we're aware of the problem we're more than happy to get it fixed via a future point release; as with any such update, minimal, targetted and well tested patches are appreciated. Regards, Adam -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/9ed67fdb1a765f1a4a2a3a5cf71c58d5.squir...@adsl.funky-badger.org
Re: Release file changes
On Mon, 2011-02-21 at 20:58 +0100, Joerg Jaspert wrote: > >>> until today our Release files included 3 Hashes for all their entries: > >>> MD5SUM, SHA1, SHA256. I just modified the code to no longer include > >>> MD5SUM in *all* newly generated Release files. > >> When will that affect Release files for stable? Next point release? > >> Because that unfortunatly completly breaks debmirror.. > > It did suddenly change for squeeze-updates without consultation with the > > suite admins. I expect that this is reverted. > > Good laugh that is. In any case, it would seem logical for squeeze and squeeze-updates to use the same set of hashes, imho; similarly the -proposed-updates suites. Each of the "sister" suites would generally be expected to be consumed (for want of a better word) by the tools in the corresponding (old)stable suite. Regards, Adam -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1298319528.14573.225.ca...@hathi.jungle.funky-badger.org
Bug#615476: general: many binaries are linked with non-existent libtiff.so.3 library
severity 615476 important tag 615476 + unreproducible thanks On Sat, 2011-02-26 at 21:25 +0300, sergey wrote: > Some programs can not start because of missing libtiff.so.3 file. I suspect this is a local problem, as none of the packages in question depends on libtiff at all; I'm therefore lowering the severity and tagging this report as unreproducible for the moment. > I found libtiff.so.3 dependencies in this files on my system: > > /usr/bin/gnuplot > /usr/bin/xfe > /usr/bin/xfview > /usr/bin/xfwrite > /usr/bin/multiget > /usr/bin/xfimage > /usr/bin/xfpack I've checked the copies of each of those binaries as shipped in squeeze on i386, and none of them appear to be using libtiff.so. Please could you provide the output of "ldd -v $binary" for each of the above? Regards, Adam -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1298745818.535.6033.ca...@hathi.jungle.funky-badger.org
